[address-policy-wg] IPv6 PI for HOSTING

Remi Despres wrote:

>>Though there are so many failures of IPv6, an example suitable for
>>discussion here is a failure to aggregate routes.

> Avoiding the need for provider independent prefixes is an important
> goal, but IPv4 misses this goal too.

> Note, besides, that the work I started on SAM (stateless map-and-encaps

FYI, the architecturally correct solution, which is applicable both
to IPv4 and IPv6, was given in draft-ohta-e2e-multihoming-00.txt
issued on April 2000.

> (Draft-despres-sam-03 and draft-despres-softwire-mesh-sam-01
> are planned to be replaced by a better successor for IETF77).

FYI, selection of the proper address requires the concept of
time out, which does not exist in connectionless IP layer, which
means the problem must be solved in transport layer (TCP) or
above (applications over UDP).

NAT-like approaches to solve the problem at the IP layer are
all broken.

> I agree that IPv6 address allocation policies still need evolution.

With 4B or 6B port numbers, the problem can be solved as address/port
allocation polices of port restricted IPv4.

> But I also believe that router and host IPv6 behaviors should

>>Another example is a problem of transport payload size. Please
>>simply answer the following question:
>>
>>	With 1280B of path MTU, how many bytes, do you think, are
>>	assured to be carried over UDP over IPv6 without
>>	fragmentation?

> Since fragmentation is in IPv6 an end-to-end function, I don't
> see why it would be important to have a fixed value for this number.

There is a reason why ISPs must filter ICMPs against fragmentation
errors. What, do you think, will happen if your access and backbone
MTU are 1500B and you send 1500B multicast packets to people many
of which are using PPPoE? If ISPs filter ICMPs against multicast
fragmentation errors, most ISPs will filter all the ICMPs.

Worse, even if fragmentation had worked, there can be indefinitely
lengthy optional headers *BEFORE* a fragmentation header that you
can not even assume fragmentation possible.

> (A sender that needs no IPv6 option may send without fragmentation
> more payload bytes than another that needs some options, e.g. for
> IPsec. Why would this be a problem?)

Because, optional header is not always under the control of
applications, as exemplified by MIPv6 headers.

> Having formats that don't limit lengths is good to have, but
> doesn't imply that there exists no practical limit.

FYI, my proposal to IPv6 WG to limit the length to allow for
512B or 1024B DNS message size was voted down, which means the
practical limit, conceived by IPv6 WG, can be as large as or
even larger than 1280B.

> In practice today, the fragmentation option having to be in
> the first packet (limited to 1280B if nothing better is
> guaranteed), and the length of options that follow being
> limited even for sophisticated uses (IPsec or mobility),
> there is AFAIK such a practical limit today.

Please simply answer the following question:

	With 1280B of path MTU, how many bytes, do you think, are
	assured to be carried over UDP over IPv6 without
	fragmentation?

If you can't, you may assume some practical upper limit on IPv6
optional header length and standardize it in IETF. Then, you can
start deploying modified specification expecting that
implementations of it will be widely deployed within the next
20 years.

>>Note also
>>that DNS (plain ones without DNSSEC) requires 512B must be carried
>>over UDP.

> No problem in IPv6, even if, due to a non typical number of
> options, datagrams would need to be fragmented.

With IPv4, header length of which is at most 60B long, fragmentation
is always possible. With IPv6, you can expect nothing.

> End to end NAT is in my understanding a proposal that eliminates
> these limitations if added to the current IPv4.

No, it's not an addition. It's a way to implement NAT, which requires
no changes on IPv4 routers in public or private IP networks.

> This works already where providers, like Free in France, offer
> native IPv6 in addition to NATed IPv4.

It's a lot of fun to see ISPs, not knowing how ICMPv6 works against
multicast fragmentation errors, say they deploy IPv6.

> IMHO, it would be useful at this stage to list IPv6 functions
> that can be used safely and usefully.

Thanks to indefinitely lengthy optional headers, no applications
work safely over IPv6.

						Masataka Ohta