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 <o...@cisco.com> > Objet : Rép : Keeping the 4rd-range issue separate from the general u/g > discussion > Date : 2013-02-05 22:42 > À : "Manfredi, Albert E" <albert.e.manfr...@boeing.com> > Cc: "ipv6@ietf.org" <ipv6@ietf.org> > >> +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 > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
