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.
From what I understand the people who really want this kind of "local"
address space want to have a *direct* assignment from a RIR or IANA.
This as it is expected that a RIR won't go belly up, a LIR might do so
though.
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.
[..]
> second, delete all of section 3.2 including subsections 3.2.1, 3.2.2, 3.2.3.
Agree.
> 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).
One thus has to setup "DNS gateway" boxes for reverse DNS which
are able to contact the global Internet to reach those machines.
If you can set those up, why not configure them directly with the
content of your *local* zones.
Also, it only covers the *reverse* of this address space, it does not
solve the *forwards* that point to the address space. It might be
just me, but users type forward more than reverses.
One will thus have to merge forward zones anyway, if you can do that
you can also setup a reverse zone at the same time.
- Introducing the ability to have ip6.arpa delegations will make sure
that the RIR will have to do more work for this. The delegations
have to point to DNS servers on the *public* Internet (strange as
we are talking about *local* addresses :) These DNS servers thus
have to be either on stable IP's (as such every such organization
requires to have also a Public PI space for this solely (they can't
depend on the local space to be PA so why should they for the global
block?) The other would be that they keep asking the RIR all the time
to change the DNS server delegation as they swapped ISP's again.
This thus costs the RIR a lot of resources/time/bla and thus is more
costly than having the requester simply have PI space.
If one *really* requires that there will be reverse that is
'automatically setup' (ignoring that you still have to do it for the
forward) then define in the draft the method that James Woodyatt
proposed of using synthesized reverse records for 0.0.c.f.ip6.arpa.
And then simply declaring that the highest subnet (::ffff:<64bits>)
contains at ::53 a DNS server serving reverse ip6.arpa for that zone.
Easiest of course is to simply set up the forward+reverse servers at the
point where you interconnect with the other network. If one says "but we
interconnect automatically", then also add in that automated framework a
way of exchanging DNS servers and zones.
The big question with all of this really is: why can't these people who
need this address space (still I haven't seen a good use-case*) simply
use PI? As that is what they really need, nothing else. If they need
something else, then please define why they need something else and what
that something else is. Having a solution for an unknown problem is not
the way to go IMHO.
Now, I hope that the above was constructive ;)
Greets,
Jeroen
* = I did see the one about planes flying around the world who have
their internal systems in a static /48 and when they come to other
places they can automatically interconnect to those networks, but why
can't those use PI either? :)
signature.asc
Description: OpenPGP digital signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
