[address-policy-wg] IPv6 PI for HOSTING

Masataka,

Thanks for your answer.

Comments below.

Le 5 janv. 2010 à 09:35, Masataka Ohta a écrit :

> Remi Despres wrote:
> 
>>> As a person who changed IPv6 address structure from 10+6 to 8+8,
>>> trying to make IPv6 a little better than the worst, I know very
>>> well how IPv6 fails to work.
> 
>> Not being such a person, I would be interested in learning in what
>> "IPv6 fails", as you say.
>> (Just stating that IPv6 doesn't help to solve problems!)
>> Can you, please, provide a list of failures you identify for native
>> IPv6 where it is available in addition to IPv4 (leaving out
>> Teredo, 6to4 and ISATAP, which are not IPv6 per se).
> 
> 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 for simplified mesh-softwire topologies) is precisely expected to lead to a solution in IPv6. (Draft-despres-sam-03 and draft-despres-softwire-mesh-sam-01 are planned to be replaced by a better successor for IETF77). 

>> References to written material would be appreciated.
> 
> IPv6 address allocation policies are the written material.
> 
> Never say there are ongoing effort to solve the problem, as I know
> similar efforts have failed several times, already.

I agree that IPv6 address allocation policies still need evolution.

But I also believe that router and host IPv6 behaviors should be complemented for these policies to fully take advantage of the IPv6 potential concerning multihoming and renumbering.


> 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.
(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?)
   
> Note that IPv6 optional headers can be indefinitely long.

The format indeed permits it.
Having formats that don't limit lengths is good to have, but doesn't imply that there exists no practical limit.  

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.

> 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. 

> 
>> o peer-to-peer applications would work better where IPv4 is
>> available only through cascades of NATs.
> 
> I'm afraid you mean "better than" and peer-to-peer applications have
> difficulties to run over NAT, especially cascaded NAT, which is not
> the case with end to end NAT.

I meant that in IPv6 P2P always works, while in IPv4 it works only with limitations if via NATs.

End to end NAT is in my understanding a proposal that eliminates these limitations if added to the current IPv4.
But these limitations can also be eliminated by using IPv6.
This works already where providers, like Free in France, offer native IPv6 in addition to NATed IPv4.

IMHO, it would be useful at this stage to list IPv6 functions that can be used safely and usefully. This could result in the definition of an *IPv6 basic-user profile*.


Regards,

RD