> 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?
nothing as such. the difference with gi-6rd is that you also need to encode the 'customer id' in the address. cheers, Ole >> 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
