In message <CAD6AjGS1SQz9ns0epA+ysiwHO4EG=XZhH-XZASVN_vXaPCWGCg@xxxxxxxxxxxxxx> , Cameron Byrne writes: > On Mon, Feb 13, 2012 at 2:06 PM, Mark Andrews <marka@xxxxxxx> wrote: > > > > In message <201202132046.q1DKk1hN020697@xxxxxxxxxxxxxxxxxxx>, Martin Rex = > writes > > : > >> Brian E Carpenter wrote: > >> > > >> > On 2012-02-14 05:51, Noel Chiappa wrote: > >> > > =A0 =A0 > From: Arturo Servin <arturo.servin@xxxxxxxxx> > >> > > > >> > > =A0 =A0 >> Are you volunteering to buy everyone on earth a new CPE? = > If not, w > >> ho > >> > > =A0 =A0 >> do you suggest will? > >> > > > >> > > =A0 =A0 > I suggest the ISPs, they are charging for the service, rig= > ht? > >> > > > >> > > Lots of CPE is actually owned by the customers, not the ISPs. E.g. i= > n our > >> > > house, both our cable modem and the router attached to it are ours. > >> > > >> > Sure, that's very common, but these devices are consumer electronics a= > nd > >> > will get gradually replaced by IPv6-supporting boxes as time goes on. > >> > (That is not hand-waving, the generation of boxes with IPv6 support is > >> > starting to appear.) Nobody, I think, is denying that there will be a = > long > >> > period of coexistence as a result. > >> > > >> > That is a separate question from this draft, which gives ISPs space fo= > r > >> > *growing* their IPv4 customer base. I think that is what upsets people= > . > >> > >> > >> The problem of ISP not newly shipping CPE that is not IPv6 capable > >> needs to be addressed by regulatory power (legistation), rather than > >> by ignorance of the part of the IETF. > >> > >> > >> ISPs *growing* their IPv4 customer base is a natural side effect > >> whenever ISPs allow customers to use equipment that they already > >> have (and might have been using with a different ISP before). > > > > You grow your IPv4 customer base by having new customers independent > > of whether they are IPv6 customers as well. =A0I don't think there > > is a customer that only wants to connect to IPv6 sites. > > > > Having IPv6 doesn't even cut down on needing to supply IPv4 unless > > you have bleeding edge IPv6 equipment. =A0People still need to connect > > to IPv4 literals and that will, for a quite a while yet, mean > > supplying a dual stack service. > > > > NAT64 doesn't have a way to inform the CPE on the mapping needed. > > It would be simple to do with DHCP but know one had written what > > needs to be in the option. > > > > Similarly 464XLAT doesn't provide a way for the CPE to find the > > prefix. =A0Blindly performing 464XLAT has similar issues to blindly > > performing 6to4. > > > > 464XLAT may indeed discover the PREF64 using > http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-05 draft-ietf-behave-nat64-discovery-heuristic-05 really isn't a solution. It doesn't say anything about choosing the A records such that there is no abmiguity when look for the embedded address. It doesn't have the exceptions which are part of DNS64. This means you can't use it reliably with dual stack internal and IPv6-only external. Below is the DNS64 configuration elements from named. dns64 <netprefix> { break-dnssec <boolean>; clients { <address_match_element>; ... }; exclude { <address_match_element>; ... }; mapped { <address_match_element>; ... }; recursive-only <boolean>; suffix <ipv6_address>; }; While not all of them are required for IPv4 literals more than netprefix and suffix are required which is all draft-ietf-behave-nat64-discovery-heuristic-05 delivers. > Running code says 464XLAT works with IPv4 literals, IPv4 referrals, > and IPv4 socket APIs. > CB > > > DS-Lite only became a RFC in the second half of 2011. =A0It will take > > some time for IPv6 equipment vendors to add support (hosts and > > routers). > > > >> The vast majority of customers does not know or care about not having IP= > v6, > >> because there is _very_ few equipment that is vitally dependent on IPv6, > >> vs. huge amounts of equiment that requires IPv4. =A0If I had a CPE that > >> supported IPv6 (mine is from early 2006 an IPv4-only), my concern would > >> be how to reliably switch IPv6 off, because of the unsolved security and > >> privacy problems that IPv6 brings along. > >> > >> > >> It was the IETFs very own decision to build IPv6 in a fashion that it is > >> not transparently backwards compatible with IPv4. =A0If the is anyone to > >> blame for the current situation, than it is the IETF, not the consumers > >> or the ISPs (except for those folks at ISPs who participated in the > >> development of IPv6). > >> > >> > >> -Martin > >> _______________________________________________ > >> Ietf mailing list > >> Ietf@xxxxxxxx > >> https://www.ietf.org/mailman/listinfo/ietf > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= > c.org > > _______________________________________________ > > Ietf mailing list > > Ietf@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf