Re: Keeping the 4rd-range issue separate from the general u/g discussion

[Rémi Després <[e-mail]>]

Bob,

This is, in my understanding,  what should be avoided in 6man, a debate on new 4rd modifications:
- The 4rd design has been stabilized for long in Softwire.
- The question to 6man is ONLY whether the proposed reserved range is compatible with the IPv6 addressing architecture.

Thanks,
RD



> De : Ole Troan <[e-mail]>
> Objet : Rép : Keeping the 4rd-range issue separate from the general u/g discussion
> Date : 2013-02-05 22:42
> À : "Manfredi, Albert E" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> 
>> +1
>> 
>> If a better alternative is devised for 4rd, as Roland proposes here, then can we deprecate the u/g bit usage? Seems to me that privacy addresses are preferable anyway, if not DHCP or statically assigned ones, so any importance assigned to u/g surely becomes a historical artifact?
> 
> indeed.
> 4rd tries to solve the problem of having a 4rd CE located behind the CPE (that receives the IPv6 delegated prefix).
> the current  4rd solution is to try to share the on-link /64 that is also used by native hosts.
> 
> for a single shared IPv4 address, I believe a 4rd CE would require 2^16 addresses. (the last 16 bits are used for the CNP).
> i.e. a /112.
> 
> the problematic assumption 4rd makes, is that it requires these addresses without having a mechanism to do duplicate address
> detection.
> 
> what are the alternatives to a fixed reservation of the interface-id space proposed?
> 
> 1) pick a separate /64 for the purpose of the 4rd function. an automated mechanism for prefix assignment is being worked
>   on in homenet. (draft-arkko-homenet-prefix-assignment-03) 
> 
> 2) defend the 4rd CE address space using DAD. pick 64K addresses out ::0:a.b:c.d:CNP.
>    chances of a conflict are small, and you would be able to detect and defend those for nodes trying to take that address
>    after the 4rd CE comes up. I wouldn't recommend doing DAD on every address first. so you may end up in a situation
>    where you encounter a conflict while in operation. that should be possible to handle though.
> 
> 3) remove the CNP feature that makes 4rd require so many addresses to function.
> 
> either of these are 
> cheers,
> Ole
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------