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
