On Thu, 28 Jun 2007, Jeroen Massar wrote:
Paul Vixie wrote:
[..]
first, in 3.1, this table:
[..]
should be replaced with this one:
| 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits |
+--------+-+----------+---------+---------+----------+
| Prefix |L| Reserved | RIR Num | LIR Num | User Num |
+--------+-+----------+---------+---------+----------+
Looks okayish but does bring back the idea of sTLA's a bit. But there is
another thing that this causes: it sort of allows aggregation.
How is this any different at all from what I proposed in another
message: One setups an organization called "Local IP Addresses Org" and
sets up an LIR, requests a /32, one one has 65k /48's to provide to
endusers. Members have a share in the org, and each and every single one
of them can already make sure that the LIR fees are paid (there are no
equipment or transit etc fees) and presto. You have EXACTLY what you
have above, but with the added benefit that it is globally unique
address space with full RIR support. The LIR can shoot ip6.arpa
delegations per /48 if they want directly into the RIR's nameservers,
thus that is also covered. Connectivity one could also provide just like
a normal LIR if really wanted.
Another problem with the above is that it doesn't allow for direct
end-user assignments. Folks still have to go through a LIR. This thus
doesn't provide these people with a "direct assignment" and they are
still bound to the LIR.
too complicated and see bellow why.
<snip>
As such, if you really want to have ULA-C (which I really think is
unnecessary because of arguments I've reiterated a couple of times
already also in other messages and the above) I would at least propose:
| 7 bits |1| 8 bits |16 bits| 16 bits | 16 bits | 64 bits |
+--------+-+--------+-------+---------+-----------+-----------+
| Prefix |L|Reserved|RIR ID | Site ID | Subnet ID | Iface ID |
+--------+-+--------+-------+---------+-----------+-----------+
| /48 for the end-site |
+-----------------------+
Same scheme of allocation, but takes out the LIR portion and thus allows
RIR's to delegate this directly to endusers.
no, just forget all of that. The original text from Paul have the solution
to this very clear:
<paste>
RIR Num Identifiers assigned by IANA for each /16 as
allocated to an Regional Internet Address
Registry
(RIR). For direct allocations by IANA, the value
of zero (0x0000) is reserved.
LIR Num Identifiers assigned by RIR for each /32 as
allocated to a Local Internet Address Registry (LIR).
For direct allocations by an RIR, the value of
zero (0x0000) is reserved.
</end paste>
so we don't have to consider this at all!! All we have todo is let IANA,
or other parties getting this task from IANA, run something automatic on
THEIR side that give end-user direct request possibility without going
through a RIR or LIR.
This solution suite the need at my workplace perfect.
<snip>
third, replace section 7.0 with the following:
Don't agree at all. (btw it is fc00::/7 not fc::/7 :)
The moment you introduce support for IP6.ARPA (not IN-ADDR.ARPA) and
require delegations to be possible there really is no difference between
PI and this kind of address space (except the prefix from which they are
allocated, they can be filtered on that but still).
The reasons against having support for reverse DNS:
- You are introducing a *local* space into the *global* Internet.
As such it is required to have Internet connectivity (with all the
hacks that are required to be able to talk to the ip6.arpa servers
and the chain along it to get to those reverse DNS servers).
as someone said to me earlier... in times of complicated affairs and
compromisses you might have to swallow a few hard pills... I dislike the
thought of ULA-C but this latest suggestion is reasonable and not that
bad. Even with DNS in place it is acceptable for me personaly this way of
doing it.
It has been said very clear by many that ULA-C is _not_ considered to be
global reachable and if we just can as strong as possible make it clear
DURING requesting of addresses we should be fine. The point is that we
have to show the enduser that they have agreed that they can NOT demand
global routing of this address space at all. No complicated text, keep it
simple.
--
------------------------------
Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID
[EMAIL PROTECTED] | - IPv6 is The Key!
-------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
