Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt

[Jeroen Massar <[e-mail]>]

[Two for the price of one response, response to James far below]

Paul Vixie wrote:
> Jeroen Massar <[e-mail]>:
>> Paul Vixie <[e-mail]>:
>>>       | 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.
> 
> i'd say deliberately not.  if LIR's receive /48's then when they hand out
> address space to end sites it'll be in groups of 5 and 10 /64's.

This is not according to current RIR policies or according to current
IETF numbering plans. It also completely ignores the EUI-64 paradigm.
When the bits are assigned to an operator they can already choose to do
whatever they want with it.

A site currently gets a /48. If that has to change then support
draft-narten-iana-rir-ipv6-considerations to change that (I do btw as
endsite will never ever ever use a /48 under normal circumstances, and a
/56 will be enough for an expected 99% of them).

>> 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.
> 
> you are so prolific here that your own words got lost in your own torrent?

I can draw it out if you want (you know how this works, but here goes):

+------+       +-----+       +-----+       +---------+
| IANA | ----> | RIR | ----> | LIR | ----> | Endsite |
+------+       +-----+       +-----+       +---------+

This is how current address assignments are done:
* IANA has it all
* RIR gets a chunk allocated from IANA
* LIR gets a chunk allocated from RIR
* Endsites get an assignment (not an allocation) from their LIR.

To note, you have "LIR" in your address diagram, and thus similar with
current policies, the endsite gets a block from the LIR, not from the
RIR, as such there is _no_ direct assignment from RIR to Endsite, and
that is (from what I understand) what people 'needing' ULA-C kind of
addresses want as they have a fear of the LIR going belly up and them
loosing their assignment.

What I proposed, lets rewrite it again: Several Endsites together set up
a single LIR, they request a /32, take /48's out of this and use this
for 'private space'. Presto. In current address space and not requiring
any changes updates or new weird rules. Also covers forward/reverse etc.

I have to note that "LIR" is a bit different term in RIPE and ARIN land,
thus it might be that that is the confusing part, in APNIC and some
other regions there are also NIR's in the chain. Making the last part
(LIR + User Num) into "User Num" would resolve this.

>> 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.
> 
> except that payments and shares are out of scope, you might be right.

Isn't the MAIN reason that people want ULA-C that they want it "CHEAP"!?
How is it then suddenly out of scope?

Also, clearly by defining ULA-C this shows that there is a price on
address space, I hope that at least the IETF is not going there.

>> 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.
> 
> then you didn't read my text, because it says the opposite of that assertion.

See my IANA->RIR->LIR->Endsite Diagram, and then check the "RIR" and
"LIR" portion in your address-diagram. Because you include LIR there can
not be a direct endsite allocation. If you would change that, as I did
in my proposed diagram to a "Prefix|L|Res|RIR|SiteID|UserBits" then you
can have a direct assignment from RIR->Endsite. (Changed "Subnet|Iface"
to "UserBits" to show that those bits really are determined by the
network operator and nobody else.

[..]
> i don't use /64's for my links.

And nobody forces you or anybody else to do so. All the other IETF
documents do include them though and if this defines address space it
should include them also IMHO. Though, I can certainly live when it is
just defined as "user defined space".

> EUI64 is going to die, and die hard.

I did not see a draft about it yet. But I do understand your arguments
for it. Still, as mentioned, the address space belongs to the operator,
let them enjoy using it. The trick of course is that devices actually do
support routing on the full 128 bits, but that is afaik still the case
with current hardware and also implicit in the IPv6 RFCs.

> let's not overspecify the mantissa.  i said "80 bits for User Num" and i meant that.
> (if someone wants to use /64's for their links, they can do that under this
> proposal, but we can't reasonably require it, and the recommendations for it
> are already present in plenty of other RFCs.)

I can agree with the above.

>> Same scheme of allocation, but takes out the LIR portion and thus allows
>> RIR's to delegate this directly to endusers.
> 
> read my text.  direct allocations are already possible.

No they are not, as a LIR is not an endsite. As such an endsite always
has to go to a LIR. That is also the whole point of PI.

Taking the LIR part out of the address diagram would resolve that part
of my comment.

>>> third, replace section 7.0 with the following:
>> Don't agree at all. (btw it is fc00::/7 not fc::/7 :)
> 
> i've seen plenty of people say fc00::/7 and i just don't get it.  you might
> as well say fc00:0000:0000:0000:0000:0000:0000:0000/7.

Well it is simple hex math: 0xfc00 != 0x00fc

Unless you are mixing up Big Endian and Little Endian comparisons.
The /7 would always mask out the last 121 bits as such fc::/7 == ::/7
and thus is wrong.

According to you is "fc::1" == "fc00:0000:0000:0000:0000:0000:0000:0001"
or is it "00fc:0000:0000:0000:0000:0000:0000:0001" ?

See the ambiguity? Also when you have the first (fc00::1) and take the
/7 it will become fc00::/7, while the latter would be come ::/7.

> when i wrote the
> reference implementation of inet_ntop(), i only emitted the part of the
> mantissa that was actually covered by the cidrlen.  this isn't scientific
> notation where you want to show the degree of accuracy of your measurements.

Well maybe the reference implementation is wrong? :)
But either you are wrong, or I am wrong (which is not unlikely ;), and
in either case I guess we end up fixing up a lot of software that is
already deployed and actively using it.

The actual function that will break with the above is inet_pton() which
converts from human readable to computer bits.

As you made me doubt about it, I just had to test it out. I couldn't
find a single box though (tried Linux,FreeBSD,WinXP,OpenBSD,NetBSD,AIX)
which did it the way you describe. See the test program way below so
that you can also test it out.

>> 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).
> 
> fred made a compelling case for why ad-hoc ULA-C routing precluded the kind
> of resolver config overrides that we're supposed to use for RFC 1918.  any
> ULA-C user who doesn't want their PTR's in the global DNS should not put any
> there, but it's not our place here and now to tell them that they just can't.

That is the wrong answer for this question. The question is not why they
can't, the question is why they want it. And moreover: why is PI not
good enough for this purpose?

>> 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.
> 
> this is attractive, but it's an architectural change that we'd have to review
> for other connectivity realms, like the DFZ, and i don't want to argue it as
> part of settling the ULA-C question.  if you like this idea, propose it and
> let's get into its merits and implications.

As mentioned, I don't like the idea as it solves a problem which should
be solved by other means. It also still requires that one configures
forward resolvers anyway. See below for James mail which has a much
better way to resolve this whole "reverse" problem of the ULA portion.

Anyway my ignored question again:

 Why would the global DNS have to handle *LOCAL* DNS delegations.

(Which never should occur/be used globally. Which most likely can not be
queried globally and which also has no value at all globally. Not even
thinking about security-minded folks who do not want to expose their
internal DNS names to the global world, that is why they want it
locally. Indeed one can opt to NOT use it, but then we just have lame
delegations again causing queries there to hit the DNS servers (most
likely the RIR ones).

If ULA-C is going to exist it should, just like ULA (RFC4193) should be,
included in the AS112 set of zones.


james woodyatt wrote:
> (p.s. I also like the idea of defining an anycast identifier for DNS
> resolving proxy servers in the locally preferred horizon.I understand,
> however, that *that* idea is more controversial-- though I don't
> understand why it should be.

dnsop group in Paris told me that it was something with breaking 3 holy
wars that have been discussed to death over the years.

From my POV there is no difference between a well known anycast DNS
server or an ISP telling clients that their DNS server is x.y.z.w.
Anycast is just a nice tool to make them failover easily and to provide
best service possible.

>  At the risk of derailing the topic, I'd
> like to mention that I know of at least one consumer Internet gateway
> product that advertises its DNS proxy service with IPv6 multicast DNS
> with a SRV records for _domain._udp.local and _domain._tcp.local
> pointing to the AAAA records for the gateway.  This was done because
> there was no anycast identifier for nodes on unmanaged networks to
> find their preferred DNS proxy.)

The problem with that still is that you only have 1 DNS server and that
doesn't say if it is the forward or the reverse. If one defines
<prefix>::53 to be DNS, it can only handle reverse zones, not forward as
when I ask for "example.com" to my local DNS server how is it to know
that it should ask <otherprefix>::1 for this?

Although as the above is mDNS, it might be that you can get back a
response from another server which does know how that zone works?

Nevertheless, for the "Auto-joining MANET case", the protocol that
setups the routing can also set up the DNS merger. This has to happen
anyway when the root DNS servers are in far-far-away-never-reach-land.


Greets,
 Jeroen


--
$ cc -o bla bla.c
8<==================================================================
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <arpa/inet.h>

void convert(const char *prefix, unsigned int length)
{
        struct in6_addr a6;
        char            buf[1024];
        unsigned int    i = (128/8)-1, l = 128 - length;

	if (length>128)
	{
		printf("Prefixlength for %s too large %u>128\n",
			prefix, length);
		return;
	}

        printf("%s/%u\n", prefix, length);

        /* Show us the number */
        inet_pton(AF_INET6, prefix, &a6);

        /* Show us the number without applying the prefixlength */
        inet_ntop(AF_INET6, &a6, buf, sizeof(buf));

        printf("\tntop: %s\n", buf);

        /* Zero out the last bits, thus applying the prefixlength */
        while (l > 8)
        {
                a6.s6_addr[i] = 0;
                i--;
                l-=8;
        }

        if (l > 0)
        {
                a6.s6_addr[i] &= ((0xff << l) & 0xff);
        }

        inet_ntop(AF_INET6, &a6, buf, sizeof(buf));
        printf("\tzero: %s/%u\n", buf, length);
}

int main(void)
{
        convert("fc::1",        128);
        convert("fc::2",          0);
        convert("fc::3",          7);
        convert("fc::4",          8);

        convert("fc00::11",     128);
        convert("fc00::12",       0);
        convert("fc00::13",       7);
        convert("fc00::14",       8);

        convert("00fc::21",     128);
        convert("00fc::22",       0);
        convert("00fc::23",       7);
        convert("00fc::24",       8);

        convert("ffff::31",     128);
        convert("ffff::32",       0);
        convert("ffff::33",       7);
        convert("ffff::34",       8);
        convert("ffff::35",       4);
}
==================================================================>8

fc::1/128
        ntop: fc::1
        zero: fc::1/128
fc::2/0
        ntop: fc::2
        zero: ::/0
fc::3/7
        ntop: fc::3
        zero: ::/7
fc::4/8
        ntop: fc::4
        zero: ::/8
fc00::11/128
        ntop: fc00::11
        zero: fc00::11/128
fc00::12/0
        ntop: fc00::12
        zero: ::/0
fc00::13/7
        ntop: fc00::13
        zero: fc00::/7
fc00::14/8
        ntop: fc00::14
        zero: fc00::/8
00fc::21/128
        ntop: fc::21
        zero: fc::21/128
00fc::22/0
        ntop: fc::22
        zero: ::/0
00fc::23/7
        ntop: fc::23
        zero: ::/7
00fc::24/8
        ntop: fc::24
        zero: ::/8
ffff::31/128
        ntop: ffff::31
        zero: ffff::31/128
ffff::32/0
        ntop: ffff::32
        zero: ::/0
ffff::33/7
        ntop: ffff::33
        zero: fe00::/7
ffff::34/8
        ntop: ffff::34
        zero: ff00::/8
ffff::34/4
        ntop: ffff::34
        zero: f000::/4

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------