This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] IPv6 allocations for 6RD
- Previous message (by thread): [address-policy-wg] IPv6 allocations for 6RD
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Mark Townsley
mark at townsley.net
Mon Feb 28 21:44:49 CET 2011
On Feb 28, 2011, at 3:20 PM, Gert Doering wrote: > Hi, > > On Mon, Feb 28, 2011 at 10:13:51AM +0100, Kurt Smolderen wrote: >> I strongly support the idea of assigning a smaller prefix to ISPs >> which are in a state of deploying IPv6 but need to use transitional >> mechanism for (some of) their customers. Mark has described one of >> the problems very clear in his email: if an ISP has only a /32 >> prefix and needs to use all 32 IPv4 bits in the 6rd configuration, >> only a /64 can be delivered to the home instead of the desired /56 >> or /48. Needing all 32 bits is for instance the case when an ISP >> offers internet connectivity to some of its customers via a partnership >> with another ISP. > > Without commenting on the general idea of allocating a larger chunk of > addresses to ISPs, I want to make sure that the underlying facts are > presented correctly. > > While RFC 5569 (the 6rd RFC) takes the "naive" approach of blindly mapping > IPv4 <-> IPv6 using the whole 32bits, it doesn't *have* to be that way - > the current 6rd work in the IETF (draft-ietf-softwire-ipv6-6rd-10.txt) > uses a more flexible approach: Yes! Except that is now published RFC 5969. RFC 5569 (five five six nine) describes the deployment at Free Telecom. RFC 5969 (five nine six nine) describes the IETF standards track protocol spec for 6rd. I really hope that most implementations are using RFC 5969 (certainly the commercial ones I know of are). > > ---- quote ---- > 6rd allows the SP to adjust the size of the 6rd prefix, > how many bits used by the 6rd mechanism, and how many bits are left > to be delegated to customer sites. > ... > For example, if the 6rd prefix is /32 and 24 bits of the CE IPv4 > address is used (e.g all CE IPv4 addresses can be aggregated by a > 10.0.0.0/8), then the size of the 6rd delegated prefix for each CE is > automatically calculated to be /56 (32 + 24 = 56). > ---- quote ---- > > so, depending on the size and fragmentation of the IPv4 address allocations > an ISP might have available, he could run fully-functional 6rd with "/60 to > end users" in a /36 IPv6 space (by only mapping 24 bits). > > > So what I would like to see added to this discussion is: > > - what 6rd implementations are there "out in the market" today? > (both provider and CPE side) For Cisco: Cisco has been shipping a BR (provider) side side since mid-2010. CE-side in IOS products since a few months after that. linksys gear has been part of many SP trials around the world since mid last year, and is expected to appear on retail shelves RSN. > > - what approach do they take? "always use 32 bits for mapping" or > the configurable approach from the i-d quoted above (IPv4MaskLen > 0)? The majority of deployments I have seen use IPv4MaskLen == 0. There is no arguing that provisioning is simpler in this mode. . - Mark > > > Gert Doering > -- APWG chair > -- > did you enable IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 >
- Previous message (by thread): [address-policy-wg] IPv6 allocations for 6RD
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]