Ole, The way to set up the tunnel is similar to ds-lite. The CPE will learn the TC's v6 address, then encap v4 packets into v6 to the TC. To create the v4-v6 mapping in the TC's routing table. This could be done by the TC to look at the dhcp message or by keepalive packets from the cpe. We haven't decided which way is preferred. But the tunnel itself is stateless.
Cheers, /Y On 3/31/11 4:11 AM, "Ole Troan" <[email protected]> wrote: >Lee, > >> But there is no NAT hole punching is involved, why use l2tp instead of >> stateless IPv4-in-IPv6? > >well, only because it is there, implemented and deployable. > >I missed that 4over6 is stateless, I thought it was the equivalent of a >configured IPv4 over IPv6 tunnel? > >cheers, >Ole > > > >> >> /Yiu >> >> On 3/31/11 3:29 AM, "Ole Troan" <[email protected]> wrote: >> >>> Yiu, >>> >>>>> reading drafts during the plenary post working group session. >>>>> >>>>> 1) what does this solution offer that isn't in RFC5571? different >>>>> encapsulation? >>>> >>>> Similar but there is a major difference. RFC5571 is 6over4 using >>>>l2tpv2 >>>> to >>>> punch through the NAT. This doesn't need this requirement, so l2tpv2 >>>> isn't >>>> needed. >>> >>> RFC5571 specifies both IPv4 over IPv6 and IPv6 over IPv4. >>> so the difference with this draft is that you rather want RFC2473 >>> encapsulation rather than PPP/UDP? >>> >>> the main argument for choosing L2TP in the first place, was that all >>>the >>> infrastructure was available, including LNSes, LAC implementations and >>> backend AAA infrastructure. >>> >>> doesn't this argument still hold for the hub and spoke case? >>> >>> the main short-coming of the RFC5571 as I see it is the lack of >>> provisioning... if we fixed that would 5571 be more palatable as a >>> solution? >>> >>>>> 2) host initiated. does this propose to support hosts behind a CPE? >>>>>how >>>>> would they then be >>>>> provisioned? >>>> >>>> The idea is the CPE will be the dhcp relay agent which will relay the >>>> dhcp >>>> requests from the hosts behind the CPE to the dhcp server. That said, >>>> there are details we need to sort out such as the CPE must be also >>>> provisioned an ipv4 address from the same subnet to support >>>> hair-pinning. >>>> Also the servers behind the CPE are normal servers, we need to detail >>>> how/when to create the binding in the NAT table so that it won't >>>>require >>>> the servers to send keepalive to the TC. >>> >>> the Basic IPv6 CE draft (to be RFC6204) only suggest to pass across >>>some >>> well known options from the WAN side DHCP client to the LAN side DHCP >>> server. perhaps you would suggest new text to the Advanced CE draft >>> suggesting that all unknown stateless DHCP option should be passed >>>across? >>> >>> 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
