Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-dhcp-11.txt

From: "Leaf Yeh" <[email-masked]>
Date: Fri, 6 Mar 2015 14:46:41 +0800

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.

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?

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?

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...".

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.

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?

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.  :-)

Best Regards,
Leaf

-----Original Message-----
From: Softwires [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, November 14, 2014 5:52 PM
To: [email-masked]
Cc: [email-masked]
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-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Mar 2015 21:23:35 +0100

Leaf,

> option-length should be variable. I guess the above text is wrongly copied

thanks, that was definitely a bug! I will get this fixed.

> 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”.

> 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.

> 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…"

> I-D.ietf-softwire-map.  'A' looks like the value in the field, while 'a' is

ack.

> I prefer to replace the above "the S46" to be "the S46 CE". Right?

right.

> 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

---

From: "Leaf Yeh" <[email-masked]>
Date: Mon, 9 Mar 2015 17:46:34 +0800

Leaf > b. In sec. 4.5,
>   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-masked]] 
Sent: Saturday, March 07, 2015 4:24 AM
To: Leaf Yeh
Cc: Tomasz Mrugalski; [email-masked]; Suresh Krishnan; Ted Lemon
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-dhcp-11.txt

Leaf,

> option-length should be variable. I guess the above text is wrongly 
> copied from other place.

> 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?

> 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?

> I prefer the above words could be " Such a client MUST include the 
> codes of the S46 Container option(s)...in its ORO…".

> I-D.ietf-softwire-map.  'A' looks like the value in the field, while 
> 'a' is the number of the bits.

ack.

right.

cheers,
Ole

> 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.
>