Leaf > b. In sec. 4.5, > " The OPTION_S46_PORTPARAMS option with an > explicit PSID MUST be discarded if the S46 CE isn't configured with a > full IPv4 address (e.g. IPv4 prefix). " Ole - this text is trying to cover the misconfiguration case where CE is assigned an IPv4 prefix (e.g. /24) and a PSID. that doesn’t work, as one can not have “shared IPv4 subnets, only individual addresses”.
I got it. The above words in quotation are right, if we suppose the 'full IPv4 address' is a derived address per the rules. Right? That might means the length of PSID in bits, q=o-(32-r) >= 0. (e.g. the cases, b1 & b2, as follows) b1. If o+r > 32, we can get q-bits (i.e. PSID) from the End-user IPv6 prefix. OTHO, we can also get q-bits (i.e. PSID) from OPTION_S46_PORTPARAMS. If they have not got the same length and value, we might need to drop OPTION_S46_PORTPARAMS. Right? b2. If o+r = 32, we can't get q-bits from the End-user IPv6 prefix, but might get q-bits (i.e. PSID) from OPTION_S46_PORTPARAMS. Right? b3. If o+r < 32, your above case, we don't need q-bits, so we will drop OPTION_S46_PORTPARAMS. b4. If o = 0, we can get q-bits (i.e. PSID) from OPTION_S46_PORTPARAMS. It seems we might have some case (e.g. the above case 'b1') of mis-configuration while a valid OPTION_S46_PORTPARAMS option is provided with a derived full IPv4 address. If we regard the above "full IPv4 address" as the Rule IPv4 prefix (x.x.x.x/32), then the above statement might need more change. Leaf - c. > I guess if F-Flag=0, i.e. not set, this rule is a BMR only, and is not > a FMR. That might means hub & spoke mode, right? If yes, I guess we > need more words on the hub & spoke mode in this section. Right? Ole - yes, that means H&S mode. I believe we had this discussion on the mailing list earlier, and that we came to the conclusion that we didn’t want to “re-specify” the MAP mechanism in the MAP DHCP draft, so the “more words” should be in the base specification. We can't have words on F-Flag in the base spec, which is defined in this draft. OTOH, we do have more words on mesh mode. " It is expected that in a typical mesh deployment scenario, there will be a single BMR, which could also be designated as an FMR using the F-Flag. " in sec. 4.1. I guess we could add the following: " It is expected that in a typical hub and spoke deployment scenario, there will be a single BMR while setting F-flag to be 0, which is not designated as an FMR". Leaf - d. > I prefer the above words could be " Such a client MUST include the > codes of the S46 Container option(s)...in its ORO…". Ole - what about: "Such a client MUST request the S46 Container option(s) that it is configured for in its ORO…" I preferred mime. Your above words specified the behavior, but my words specified the implementation. :-) Best Regards, Leaf -----Original Message----- From: Ole Troan [mailto:[email protected]] Sent: Saturday, March 07, 2015 4:24 AM To: Leaf Yeh Cc: Tomasz Mrugalski; [email protected]; Suresh Krishnan; Ted Lemon Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-dhcp-11.txt Leaf, > > Nits found in draft-ietf-softwire-map-dhcp-11: > > a. In sec. 4.4, "o option-length: 4" > > Per the format defined for OPTION_S46_V4V6BIND, the value of the > option-length should be variable. I guess the above text is wrongly > copied from other place. thanks, that was definitely a bug! I will get this fixed. > b. In sec. 4.5, > " The OPTION_S46_PORTPARAMS option with an > explicit PSID MUST be discarded if the S46 CE isn't configured with a > full IPv4 address (e.g. IPv4 prefix)." > > I prefer to replace the above "a full IPv4 address" to be "a shared > IPv4 address". We can get the address sharing information from the > calculation on the 'ea-len' and 'prefix4-len' got from > OPTION_S46_RULE, i.e. PSID-length = q = o - p = o - (32-r) != 0. Right? this text is trying to cover the misconfiguration case where CE is assigned an IPv4 prefix (e.g. /24) and a PSID. that doesn’t work, as one can not have “shared IPv4 subnets, only individual addresses”. > c. In sec. 4.1, > " o F-Flag: 1 bit field that specifies whether the rule is to be used > for forwarding (FMR). If set, this rule is used as a FMR, if not > set this rule is a BMR only and MUST NOT be used for forwarding. > Note: A BMR can also be used as an FMR for forwarding if the > F-flag is set. The BMR rule is determined by a longest-prefix > match of the Rule-IPv6-prefix against the End-User IPv6 > prefix(es)." > > I guess if F-Flag=0, i.e. not set, this rule is a BMR only, and is not > a FMR. That might means hub & spoke mode, right? If yes, I guess we > need more words on the hub & spoke mode in this section. Right? yes, that means H&S mode. I believe we had this discussion on the mailing list earlier, and that we came to the conclusion that we didn’t want to “re-specify” the MAP mechanism in the MAP DHCP draft, so the “more words” should be in the base specification. > d. In sec. 8, > " Such > a client MUST include the S46 Container option(s) that it is > configured for in its ORO in SOLICIT, REQUEST, RENEW, REBIND and > INFORMATION-REQUEST messages. " > > I prefer the above words could be " Such a client MUST include the > codes of the S46 Container option(s)...in its ORO…". I agree it is worded a bit awkwardly. what about: "Such a client MUST request the S46 Container option(s) that it is configured for in its ORO…" > e. In sec. 4.5, > " o offset: (PSID offset) 8 bits long field that specifies the numeric > value for the S46 algorithm's excluded port range/offset bits > (A-bits), as per section 5.1.1 of [I-D.ietf-softwire-map]. " > > I prefer to replace the above "A-bits " to be "a-bits" per > I-D.ietf-softwire-map. 'A' looks like the value in the field, while > 'a' is the number of the bits. ack. > f. In sec. 4.4, > " o bind-ipv6-prefix: a variable length field specifying the IPv6 > prefix or address for the S46. " > > I prefer to replace the above "the S46" to be "the S46 CE". Right? right. > g. In sec. 3, > " MAP-E uses RFC2473 [RFC2473] IPv4 over IPv6 tunnelling, > while MAP-T uses NAT64 [RFC6145] based translation." > > We only need 1x RFC2473 here. :-) you just can’t have enough RFC2473! ;-) I think the length bug above warrants a quick revision. if no-one objects I’ll also include the other editorial issues that Leaf found. cheers, Ole > > > Best Regards, > Leaf > > > > -----Original Message----- > From: Softwires [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Friday, November 14, 2014 5:52 PM > To: [email protected] > Cc: [email protected] > Subject: [Softwires] I-D Action: draft-ietf-softwire-map-dhcp-11.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 : DHCPv6 Options for configuration of Softwire > Address and Port Mapped Clients > Authors : Tomek Mrugalski > Ole Troan > Ian Farrer > Simon Perreault > Wojciech Dec > Congxiao Bao > Leaf Y. Yeh > Xiaohong Deng > Filename : draft-ietf-softwire-map-dhcp-11.txt > Pages : 18 > Date : 2014-11-14 > > Abstract: > This document specifies DHCPv6 options, termed Softwire46 options, > for the provisioning of Softwire46 Customer Edge (CE) devices. > Softwire46 is a collective term used to refer to architectures based > on the notion of IPv4 Address+Port (A+P) for providing IPv4 > connectivity across an IPv6 network. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-softwire-map-dhcp/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-11 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-dhcp-11 > > > 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
