The obvious answer is to use multiple 6rd domains and set IPv4MaskLen > 0 to save bits. Then, run the dhcp server on the GW (i.e. 6rd-CE) to delegate prefixes to the hosts. However, what is new in this draft rfc5969 can't do?
Thanks, Yiu On 11/8/10 5:53 AM, "Ole Troan" <[email protected]> wrote: >Tina, > >>>> Consider an operator facing a high subscriber growth rate. As a >>>> result of this growth rate, the operator faces pressure on its stock >>>> of available public IPv4 addresses. For this reason, the operator >>>>is >>>> motivated to offer IPv6 access as quickly as possible. >>>> >>>> The backbone network will be the first part of the operator's >>>>network >>>> to support IPv6. The metro network is not so easily upgraded to >>>> support IPv6 since many devices need to be modified and there may be >>>> some impact to existing services. Thus any means of providing IPv6 >>>> access has to minimize the changes required to devices in the metro >>>> network. >>> >>> what is it that makes existing softwires mesh solutions unsuitable for >>>crossing the IPv4 only metro network? I'm thinking specifically on 6PE >>>or BGP tunnels. >> Ole, thank you for asking. I didn't say that. IMHO, 6PE or BGP are more >>appropriately used in core network. There are fewer uses of MPLS in >>metro network. BGP tunnels are also more appropriate for core network. >> >> Essentially the authors are talking about a situation where 6rd is an >>applicable technology, but needs modification to meet the constraints of >>maximized savings of IPv4 addresses and no provider access to customer >>site equipment. The IPv4 address savings occur only if the customer site >>is IPv6-only, but the proposal still works for dual-stack customer >>sites. The technical solution is to move the IPv6 in IPv4 tunnel >>endpoint to the provider edge rather than have it in equipment on the >>customer site, and use the provider gateway IPv4 address in the IPv6 >>prefix given to the customer site. As Ralph pointed out, the protocol in >>RFC 5969 should be able to be applied without change. >> >> The authors will restructure the draft to illustrate this latter point. >>As Ralph suggested, it will be submitted with the intention of becoming >>an Informational describing an alternative deployment of 6rd to meet the >>constraints we described above. I hope this plan meets with the chairs' >>approval. > >1) is BGP tunneling not applicable because these devices don't support >BGP? or not support MPLS? >2) my concern with using 6rd for this purpose is that while automatic >tunneling by encoding the tunnel end point in the payload address is >convenient. offering a 'sensible' sized IPv6 prefix to end users is going >to be problematic. note this is purely a concern from a deployment >perspective. I have no doubt that you can _use_ 6rd this way. just >because we _can_, _should_ we? >can you give some examples of how you deliver e.g. /56 or /64 to end >users, using gi-6rd? (without expecting the SP to have a /16 of v6 space >obviously). > >cheers, >Ole > >_______________________________________________ >Softwires mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
