Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-dhcp-07

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 1 May 2014 19:03:24 +0000

UmmŠthat doesn¹t cut it either, since softwire node will always have to
formulate the 32-bit IPv4 address even if < /32 is conveyed.  Also,
Software interface is not defined anywhere in this document.

 How about the following -

-- 
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco

-----Original Message-----
From: Ian Farrer <[email-masked]>
Date: Friday, April 25, 2014 at 8:42 AM
To: Ole Troan <[email-masked]>
Cc: Softwires-wg list <[email-masked]>, Yong Cui
<[email-masked]>
Subject: Re: [Softwires] Working group last call for
draft-ietf-softwire-map-dhcp-07

>Hi Ole,
>
>So the whole paragraph would read:
>
>When receiving the Port Parameters option with an explicit PSID, the
>client MUST use this explicit PSID in configuring its softwire interface.
>The Port Parameters option with an explicit PSID MUST be discarded
>if the softwire node isn't configured with a full IPv4 address (e.g. IPv4
>prefix).
>
>If so, fine with me.
>
>Cheers,
>Ian
>
>On 24 Apr 2014, at 10:15, Ole Troan <[email-masked]> wrote:
>
>> Ian,
>> 
>>> When receiving the Port Parameters option with an explicit PSID, the
>>> client MUST use this explicit PSID in configuring its softwire
>>>interface.
>>> If the client¹s IPv4 address (configured via a separate sub-option)
>>> is not 32 bit-long, the Port Parameters option MUST be discarded.
>>> For MAP-E and MAP-T clients, the formula for the address length check
>>> is "prefix4-len + ea-len = 32² and serves to ensure that  the explicit
>>> PSID is only applied to configurations with a completely formed IPv4
>>>address.
>> 
>> I don't like the implications that IPv4 address can be != 32 bits. ;-)
>> 
>> just simply:
>> 
>> The Port Parameters option with an explicit PSID MUST be discarded if
>>the softwire node isn't configured with a full IPv4 address (e.g. IPv4
>>prefix).
>> 
>> ?
>> 
>> cheers,
>> Ole
>> 
>
>_______________________________________________
>Softwires mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/softwires

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 2 May 2014 18:16:45 +0000

Hi:

I'm reviewing this document from the DHC perspective and not evaluating it with respect to Softwires.

>From an options definition/formatting perspective, I think this draft follows the draft-ietf-dhc-option-guidelines-17 recommendations.

There are some minor nits that could improve the clarity of the draft:

For example:

   o  S46_RULE-options: a variable field that may contain zero or more
      options that specify additional parameters for this S46 rule, e.g.
      a Port Parameter Option.

Says "e.g. a Port Parameter Option". Are there others (today)? Be nice to be explicit as to what can appear today (future documents can always add additional options).

And, in other places when options are referenced the option name is given (so perhaps replace with OPTION_S46_PORTPARAMS)? There are similar issues in other places in the draft.

Also:

   The OPTION_S46_PORTPARAMS option MUST be encapsulated in a
   OPTION_S46_RULE option or an OPTION_S46_V4V6BIND option.  It MUST NOT
   appear directly within a container option.

5.  Softwire 46 Container DHCPv6 Options

      +-----------------------+-------+-------+--------------------+
      | Option                | MAP-E | MAP-T | Lightweight 4over6 |
      +-----------------------+-------+-------+--------------------+
      | OPTION_S46_RULE       |   M   |   M   |        N/A         |
      | OPTION_S46_BR         |   M   |  N/A  |         M          |
      | OPTION_S46_PORTPARAMS |   O   |   O   |         O          |
      | OPTION_S46_DMR        |  N/A  |   M   |        N/A         |
      | OPTION_S46_V4V6BIND   |  N/A  |  N/A  |         O          |
      +-----------------------+-------+-------+--------------------+

             M - Mandatory, O - Optional, N/A - Not Applicable

                   Table 1: Option to Container Mappings

So, the last sentence before section 5 (It MUST NOT appear directly within a container Option). But section 5 calls the two options it is allowed in Container options? Perhaps just drop that sentence? Also, the "MUST be encapsulated" seems wrong (it is optional)? Well, it all depends what is meant by this sentence. I think it is trying to say "may only" or "can only"?

This table 1 should probably have an introduction / description? Perhaps it should also be moved to the end of section 5?

It is wise to have the Security Considerations reference an expired and dead document - [I-D.ietf-dhc-secure-dhcpv6]? It is Informative, but still ... Perhaps worth adding whatever material makes sense? It looks like many of Informative references are to older (expired) draft documents?

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Tuesday, April 22, 2014 12:39 PM
To: dhcwg
Cc: Softwires-wg
Subject: [dhcwg] WGLC for draft-ietf-softwire-map-dhcp-07 in Softwires WG

Oops, that slipped under the radar for while.

I'd like to bring up to DHC attention a document that goes through WGLC in Softwires. This is a document that specifies provisioning mechanism for MAP, lw4over6 and possibly other IPv4/IPv6 transition technologies.
It defines 8 DHCPv6 options. Some of them are containers and there are many inter-option dependencies (including dependence on PD options), so it's not a straightforward doc.

Please post your DHCP-related comments to Softwires list with cc: to dhc. If you have MAP-, lw4over6- or other IPv4/IPv6 transition specific comments, please post them to Softwires only and not to DHC.

With my DHC co-chair hat off: I used to be a primary author of that draft around 1,5 years ago. Since then I gave up and didn't follow on the discussions (simply because of lack of time). While technically I'm still listed as a co-author, I can't make any comments on the quality or correctness of this draft.

Tomek

-------- Original Message --------
Subject: [Softwires] Working group last call for
draft-ietf-softwire-map-dhcp-07
Date: Mon, 7 Apr 2014 00:37:35 -0400
From: Suresh Krishnan <[email-masked]>
To: Softwires WG <[email-masked]>
CC: Yong Cui <[email-masked]>

Hi all,
  This message starts a two week softwire working group last call on advancing the draft about the DHCPv6 Options for configuration of Softwire Address and Port Mapped Clients as a Standards Track RFC. The authors believe that this version has addressed all the issues raised on the document. The latest version of the draft is available at

http://www.ietf.org/id/draft-ietf-softwire-map-dhcp-07.txt
http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-07

Substantive comments and statements of support/opposition for advancing this document should be directed to the mailing list. Editorial suggestions can be sent directly to the authors. This last call will conclude on April 21 2014.

Regards,
Suresh & Yong

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ian Farrer <[email-masked]>
Date: Mon, 5 May 2014 10:53:31 +0200

Hi Rajiv,

Please see inline.

Cheers,
Ian

> How about the following -

[ian] Incomplete suggestion, or are you saying it should be removed?

---

From: Ole Troan <[email-masked]>
Date: Mon, 5 May 2014 11:17:23 +0200

Rajiv,

> Software interface is not defined anywhere in this document.

what do you mean? a MAP node can be provisioned with an IPv4 prefix too.

cheers,
Ole

---

From: Ian Farrer <[email-masked]>
Date: Mon, 26 May 2014 13:24:59 +0200

Hi,

This one slipped my mind…. 

From a discussion with Ole during the MAP dhcp last call, there was a discussion about the exclusion of provisioning WKPs to CPEs - http://www.ietf.org/mail-archive/web/softwires/current/msg06010.html

In previous versions, the lw4o6 used to reference sun-dhc-port-set-option, which also stated that the WKPs should not be assigned. This advice got lost when changing to reference map-dhcp for PSID format.

Here’s a wording change proposal to resolve this:

Section 5.1

Original text (last sentence, para 7):

"For lw4o6, the  number of a-bits SHOULD be 0."

Proposed change:

"For lw4o6, the number of a-bits SHOULD be 0 to allocate a single contiguous port set to each lwB4.

Unless a lwB4 is being allocated a full IPv4 address, it is RECOMMENDED that PSIDs containing the well-known ports (0-1023) are not allocated to lwB4s.”

Please let me know if you are OK with the proposed change.

cheers,
Ian

> 
>> Good spot on the WKP exclusion. Before the lw4o6 draft was updated to reference map-dhcp for configuration,  the port configuration was described in sun-dhc-port-set-option, which also stated that the WKPs should not be assigned. This advice got lost when changing to reference map-dhcp. I’ll make a suggested text update for the lw4o6 draft to fix this. Does that work for you?
> 
> yes, that would be good.
> 
> cheers,
> Ole
>

---

From: Tom Taylor <[email-masked]>
Date: Mon, 26 May 2014 13:48:03 -0400

Looks good to me.

Tom