Dear all, We have submitted an updated version of lw4over6, trying to address the comments received during the IETF LC and the IESG review.
Here is a list of the comments received as well as changes we’ve made: AD Review • Update to reference RFC7341 – DHCPv4[RFC2131] -> DHCPv4 over DHCPv6[RFC7341] • Require the explanation of IPv6 binding prefix – Add text: “The IPv6 binding prefix field is provisioned so that the CE can identify the correct prefix to use as the tunnel source.” • Update Figure 3 Construction of the lw4o6 /128 Prefix – Operator Assigned -> Operator Assigned /64 prefix • Explain what happens if the public IPv4 address is changed – Add text: “When the lwB4's public IPv4 address or port set ID is changed for any reason, the lwB4 MUST flush its NAPT table.” • Fragment collision – MAP: A CE could rewrite the IPv4 fragmentation identifier, but might cause problem Gen-ART and OPS-Dir Review • Require of discussion of management information – The Softwire-YANG document is an individual draft under progress (draft-sun-softwire-yang-00), do not reference in this spec • Synchronization “companion document” needs to be cited as a normative reference in -10 – Change text to: “The precise mechanism whereby this synchronization occurs is out of scope for this document” Gen-ART and OPS-Dir Review • Which protocols are MTI for lwB4 – Only DHCPv6 provisioning is MTI • Reference to draft-ietf-dhc-dynamic-shared-v4allocation • Update the usage of RFC2119 language – Weaken any MUST requirement in the referenced RFC(s) to a SHOULD • “SHOULD” -> “MUST” in Sec 5.1, Sec 5.2.1, Sec 8.2 – Section 8.1 ICMPv4 process by the lwAFTR • “Additionally, the lwAFTR MAY implement Discarding of all inbound ICMP messages” -> MUST – “must” -> “MUST” in Sec 5.1 OPS AD Review (Benoit) • How to achieve interoperability if each implementation can choose different provisioning mechanisms? – To prevent interworking complexity, it is RECOMMENDED that an operator uses a single provisioning mechanism / protocol for their implementation. In the event that more than one provisioning mechanism / protocol needs to be used, the operator SHOULD ensure that each provisioning mechanism has a discrete set of resources. Secdir Review • Require explanation of why well-known ports are not allocated – Add text: “The system ports are more likely to be reserved by middleware, and therefore we recommend that they not be issued to clients other than as a deliberate assignment . Section 5.2.2 of [RFC6269] provides analysis of allocating well-known ports to clients with IPv4 address sharing.” • ICMPv6 error message may cause DoS attack – Add text: “On receipt of such an ICMP error message, the lwB4 MUST validate the source address to be the same as the lwAFTR address which is configured. In the event that these addresses do not match, the lwAFTR MUST discard the ICMP error message. In order to prevent forged ICMP messages using the spoofed lwAFTR address as the source being sent to lwB4s, the operator can implement network ingress filtering as described in [RFC2827].” And add text in Sec 9: “The lwAFTR MUST rate limit ICMPv6 error messages (see Section 5.1) to defend against DoS attacks generated by an abuse user." Secdir Review • Require discussion of provisioning mechanism security – Add text in Security Considerations: “This document describes a number of different protocols which may be used for the provisioning of lw4o6. In each case, the security considerations relevant to the provisioning protocol are also relevant to the provisioning of lw4o6 using that protocol. lw4o6 does not add any addiLonal provisioning protocol specific security considerations.” • Require the discussion of additional port space after the initial assignment – Added text: “DHCPv6 based provisioning does not provide a mechanism for the client to request more L4 ports, Other provisioning mechanisms (e.g. PCP based provisioning) provide this function.” David Harrington - • In section 5.2.1 “Changes to RFC2473 and RFC6333 Fragmentation Behavior”. Not clear on what the changes to these RFCs are – Section title has been renamed as just 'Fragmentation Behaviour’ Best Regards, Qi Begin forwarded message: > From: [email protected] > Subject: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-12.txt > Date: November 11, 2014 at 5:32:19 PM GMT+8 > To: [email protected] > Cc: [email protected] > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Softwires Working Group of the IETF. > > Title : Lightweight 4over6: An Extension to the DS-Lite > Architecture > Authors : Yong Cui > Qiong Sun > Mohamed Boucadair > Tina Tsou > Yiu L. Lee > Ian Farrer > Filename : draft-ietf-softwire-lw4over6-12.txt > Pages : 22 > Date : 2014-11-11 > > Abstract: > Dual-Stack Lite (RFC 6333) describes an architecture for transporting > IPv4 packets over an IPv6 network. This document specifies an > extension to DS-Lite called Lightweight 4over6 which moves the > Network Address and Port Translation (NAPT) function from the > centralized DS-Lite tunnel concentrator to the tunnel client located > in the Customer Premises Equipment (CPE). This removes the > requirement for a Carrier Grade NAT function in the tunnel > concentrator and reduces the amount of centralized state that must be > held to a per-subscriber level. In order to delegate the NAPT > function and make IPv4 Address sharing possible, port-restricted IPv4 > addresses are allocated to the CPEs. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-12 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-lw4over6-12 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
