I see the "customer id" is local to the gw. This is why I don't see a new draft is needed. However, the major challenge is even fewer bits are available for the CPE.
On 11/8/10 9:33 AM, "Ole Troan" <[email protected]> wrote: >> 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
