Hi Ole, But there is no NAT hole punching is involved, why use l2tp instead of stateless IPv4-in-IPv6?
/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
