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
