Leaf, thanks, let's see if we can get these in during the AUTH48.
cheers, Ole > On 15 Feb 2015, at 9:20 , Leaf Yeh <[email protected]> wrote: > > I got a late read on this draft, and may find some editorial nits: > > #1. In sec. 3, > " End-user IPv6 prefix: The IPv6 prefix assigned to an End-user CE by > other means than MAP itself. E.g., > Provisioned using DHCPv6 PD [RFC3633], > assigned via SLAAC [RFC4862], or configured > manually. It is unique for each CE. " > > Q. Does the above means ' End-user IPv6 prefix ' includes 's bits' (the > subnet ID) in Fig.3? > > But in sec. 5.2, > " The MAP IPv6 address is created by concatenating the End-user IPv6 > prefix with the MAP subnet identifier (if the End-user IPv6 prefix is > shorter than 64 bits) and the interface identifier as specified in > Section 6. " > > Q. Does the above means ' End-user IPv6 prefix ' does not include 's bits' > (the subnet ID) in Fig.3? I guess we could include 's bits' (the subnet ID= > MAP subnet identifier) into ' End-user IPv6 prefix '. > > And in sec. 6, > " If the End-user IPv6 prefix length is larger than 64, the most > significant parts of the interface identifier is overwritten by the > prefix. " > > Q. Does the above means ' End-user IPv6 prefix ' includes 's bits' (the > subnet ID) in Fig.3? > > > #2. In sec. 5.1, > " For 'a' > 0, A MUST be > larger than 0. This ensures that the algorithm excludes the > system ports. For the default value of a (6), the system ports, > are excluded by requiring that A be greater than 0. Smaller > values of a excludes a larger initial range. E.g., a = 4, will > exclude ports 0 - 4095. The interval between initiaL port numbers > of successive contiguous ranges assigned to the same user is > 2^(16-a). " > > I prefer the above sentence could be > " For 'a' > 0, 'A' MUST be > larger than 0. This ensures that the algorithm excludes the > system ports. Smaller > values of 'a' excludes a larger initial range; e.g. 'a' = 4, will > exclude ports 0 - 4095. The interval between initial port numbers > of successive contiguous ranges assigned to the same user is > 2^(16-a). " > > > #3. In Fig.7 of sec. 5.3, > “ +----------+ +------------+ > |IPv4 sufx| |Port-Set ID | > +----------+ +------------+ ” > I prefer the above ‘sufx’ could to be ‘suffix’. > > > #4. In sec.6, > “ The PSID field is left-padded to create a > 16 bit field. For an IPv4 prefix or a complete IPv4 address, the > PSID field is zero.” > > Q. Does the about ‘zero’ means the value of the PSID=0x 00, or the length of > the PSID is zero? I guess it means the former, right? > > > #5. In Fig.8 of sec.6, > “The Interface identifier format of a MAP node is described below. > | 128-n-o-s bits | > | 16 bits| 32 bits | 16 bits| > +--------+----------------+--------+ > | 0 | IPv4 address | PSID | > +--------+----+-----------+--------+ ” > > I think BR does not need to use the above IID. I prefer to replace the word > ‘MAP node’ to be ‘MAP CE’. Right? > The above format looks like ‘128-n-o-s =64, but that is not always true. I > prefer the IID format of MAP CE could be: > | 128-n-o-s bits | > | <=16 bits| 32 bits | 16 bits| > +--------+----------------+--------+ > | all 0s | IPv4 address | PSID | > +--------+----+-----------+--------+ ” > > > #6. In sec. 8.1, > “ Secondly, the node extracts the source IPv4 > address and port from the IPv4 packet embedded inside the IPv6 > packet. If they are found to be outside the acceptable range, the > packet MUST be silently discard and a counter incremented to indicate > that a potential spoofing attack may be underway.” > > I guess the better to substitute the above word ‘embedded’ could be > ‘encapsulated’, right? > > > #7. In sec. 11 > “ They cannot > exist with MAP because each BRs checks that the IPv6 source > address of a received IPv6 packet is a CE address based on > Forwarding Mapping Rule. ” > > I think BRs check that the IPv6 source address of a received IPv6 packet is a > CE address based on Basic Mapping Rule, and check that the IPv6 destination > address of a received IPv6 packet is a CE address based on Forwarding Mapping > Rule, right? > > > Best Regards, > Leaf > > > > -----Original Message----- > From: Softwires [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Monday, November 24, 2014 3:39 PM > To: [email protected] > Cc: [email protected] > Subject: [Softwires] I-D Action: draft-ietf-softwire-map-12.txt > > > 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 : Mapping of Address and Port with Encapsulation (MAP) > Authors : Ole Troan > Wojciech Dec > Xing Li > Congxiao Bao > Satoru Matsushima > Tetsuya Murakami > Tom Taylor > Filename : draft-ietf-softwire-map-12.txt > Pages : 32 > Date : 2014-11-23 > > Abstract: > This document describes a mechanism for transporting IPv4 packets > across an IPv6 network using IP encapsulation, and a generic > mechanism for mapping between IPv6 addresses and IPv4 addresses and > transport layer ports. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-softwire-map/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-softwire-map-12 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
