Remi, the point I'm trying to make is that the future of 4rd does not depend on 6man accepting the request for a reserved space. 4rd can function very well without it.
cheers, Ole > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
