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

From: Suresh Krishnan <[email-masked]>
Date: Mon, 7 Apr 2014 00:37:35 -0400

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

---

From: Xing Li <[email-masked]>
Date: Wed, 16 Apr 2014 18:56:57 +0800

I support advancing this document. It defines the provisioning mechanism 
for map-e, map-t and lw4o6. xing

Suresh Krishnan 写道:
> authors believe that this version has addressed all the issues raised 
> on the document. The latest version of the draft is available at
>
> 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
>
>
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>
>

---

From: Ian Farrer <[email-masked]>
Date: Thu, 17 Apr 2014 17:10:52 +0200

Hi,

I have one question about the draft as it stands at the moment:

Currently, OPTION_S46_BR is limited to only be a sub-option carried within one of the S46 container options (described in section 3). However, other softwire provisioning mechanisms also need this configuration parameter, for example if you’re using DHCPv4 over DHCPv6.

To re-use this parameter for DHCPv4o6 as it stands within the container would be very messy: A client needs to indicate its support for OPTION_S46_CONT_LW and DHCPv4o6 in the ORO, it then gets the parameter from one end of the softwire from DHCPv6 and the other end of the softwire using DHCPv4o6.

Two solutions spring to mind:

1, Loosen the restriction in this draft so that OPTION_S46_BR can be used outside of one of the S46 Containers. This would then allow the possibility of the client including the option within an ORO option in the DHCPV4-QUERY/RESPONSE messages in the DHCPv4o6 message flow.
2, Keep the restriction in the map-dhcp draft and create a new option for provisioning the BR specifically for softwire clients using DHCPv4o6.

The outcome of this may also have a knock on effect of what’s going to be possible if we ever resurrect the unified-cpe work.

And two comments on section 4.5:
This section is entirely MAP specific, although the sub-option is generally applicable to all of the containers.
The default value of 6 for the ‘offset’ field either shouldn’t be specified here, or should have ‘6’ for MAP and ‘0’ for lw4o6.

Cheers,
Ian

On 7 Apr 2014, at 06:37, Suresh Krishnan <[email-masked]> wrote:

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

---

From: Ole Troan <[email-masked]>
Date: Tue, 22 Apr 2014 15:07:10 +0200

Ian,

> To re-use this parameter for DHCPv4o6 as it stands within the container would be very messy: A client needs to indicate its support for OPTION_S46_CONT_LW and DHCPv4o6 in the ORO, it then gets the…

is the complete flow and options of how LW46 is provisioned with DHCPv4 described anywhere? half and half with DHCPv6 options and DHCPv4 options?

> The outcome of this may also have a knock on effect of what’s going to be possible if we ever resurrect the unified-cpe work.

if you need the OPTION_S46_BR option in particular, perhaps something else as well? I think the cleanest would be to specify a new container option for this "mode".

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 22 Apr 2014 15:17:36 +0200

Ian,

> This section is entirely MAP specific, although the sub-option is generally applicable to all of the containers.

while I think it is fine that it refers to the "MAP algorithm", I agree it shouldn't refer to "MAP interface". would you have a go at more generic text?

> The default value of 6 for the ‘offset’ field either shouldn’t be specified here, or should have ‘6’ for MAP and ‘0’ for lw4o6.

we might not need to include that in the map-dhcp document, since it is already in map base.
btw, is '0' a wise choice for LW46? I don't see any evaluation or recommendations in the LW46 document about what to do with a PSID of 0 and an offset of 0. try sourcing a few packets from TCP port 25 to random picked destination, to understand my point.

cheers,
Ole

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 22 Apr 2014 18:38:52 +0200

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,

Regards,
Suresh & Yong

---

From: Ian Farrer <[email-masked]>
Date: Wed, 23 Apr 2014 14:35:55 +0200

Hi Ole,

Please see inline.

Cheers,
Ian

> while I think it is fine that it refers to the "MAP algorithm", I agree it shouldn't refer to "MAP interface". would you have a go at more generic text?

[ian] Couple of changes to 4.5:

Old:
The Port Parameters Option specifies optional Rule Port Parameters
   that MAY be provided as part of the Mapping Rule for CEs using the
   MAP algorithm.
New:
The Port Parameters Option specifies optional Port Set information
   that MAY be provided to CEs.

Old:
When receiving the Port Parameters option with an explicit PSID, the
   client MUST use this explicit PSID in configuring its MAP interface.
   If the conveyed IPv4 address is not 32 bit-long, the option MUST be
   discarded.  The formula for this 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.
New:
On receipt of the Port Parameters option with an explicit PSID, clients
   MUST configure their softwire interface with the received
   explicit PSID. For MAP-E and MAP-T clients, if the conveyed IPv4 address
   is not 32 bits-long, the option MUST be discarded.  The formula for 
   this 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.

> btw, is '0' a wise choice for LW46? I don't see any evaluation or recommendations in the LW46 document about what to do with a PSID of 0 and an offset of 0. try sourcing a few packets from TCP port…

[ian]
What about the following wording change: 
Old:Allowed values are between 0 and 15, with the default value being 6.
New:
Allowed values are between 0 and 15. Default values for this field are specific to the softwire mechanism being implemented and  are defined in the relevant specification document. 

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?

---

From: Ole Troan <[email-masked]>
Date: Wed, 23 Apr 2014 15:47:11 +0200

Ian,

thanks!

>   that MAY be provided to CEs.

that looks fine.

>   the explicit PSID is only applied to configurations with a completely

what about keeping the old text with your change of s/MAP interface/softwire interface/.
at least in theory LW46 could support IPv4 prefixes, or a new mechanism could come along that did.

> Allowed values are between 0 and 15. Default values for this field are specific to the softwire mechanism being implemented and  are defined in the relevant specification document. 

that looks fine. updated.

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

yes, that would be good.

cheers,
Ole

---

From: Ian Farrer <[email-masked]>
Date: Wed, 23 Apr 2014 16:52:36 +0200

Hi Ole,

> at least in theory LW46 could support IPv4 prefixes, or a new mechanism could come along that did.

[ian] Actually, looking at this again, the original text isn’t particularly clear. It talks about provisioning ports sets, and then makes a leap to the length of the IPv4 address, which is not conveyed in this option. Also, the 32 bit address checking logic is MAP specific. So:

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.

Cheers,
Ian

---

From: Tom Taylor <[email-masked]>
Date: Wed, 23 Apr 2014 14:52:05 -0400

>> 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…
On the WKP exclusion, you might point people to the last paragraph of 
Appendix B.1 in draft-ietf-softwire-map.

Tom

---

From: Ole Troan <[email-masked]>
Date: Thu, 24 Apr 2014 10:15:57 +0200

Ian,

> 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

---

From: Tom Taylor <[email-masked]>
Date: Thu, 24 Apr 2014 22:02:31 -0400

I'm a bit late on this, but it comes from trying to sort out what the 
underlying information will look like as Diameter AVPs coming from AAA. 
This is just a question for clarification.

As indicated in Section 5, bullet 1 of the MAP-E document, a MAP CE can 
be provisioned with multiple End-user IPv6 prefixes, each associated 
with its own Basic Mapping Rule.

If I read things correctly in section 5.1 of 
draft-ietf-softwire-map-dhcp-07.txt, there are two cases:
  (1) Multiple domains: multiple instances of OPTION_S46_CONT_MAPE will 
be present.

  (2) Single domain, multiple subnets: multiple instances of 
OPTION_S46_RULE will be present within a single instance of 
OPTION_S46_CONT_MAPE.

In either case, the correlation between the End-user IPv6 prefix and its 
corresponding Basic Mapping Rule is achieved through longest match. A 
good CPE implementation will validate that there is a 1-1 correspondence 
between the BMRs and the provisioned End-user IPv6 prefixes.

Is my understanding correct?

Tom Taylor

---

From: Ole Troan <[email-masked]>
Date: Fri, 25 Apr 2014 10:11:57 +0200

Tom,

> I'm a bit late on this, but it comes from trying to sort out what the underlying information will look like as Diameter AVPs coming from AAA. This is just a question for clarification.
> 
> As indicated in Section 5, bullet 1 of the MAP-E document, a MAP CE can be provisioned with multiple End-user IPv6 prefixes, each associated with its own Basic Mapping Rule.
> 
> If I read things correctly in section 5.1 of draft-ietf-softwire-map-dhcp-07.txt, there are two cases:
> (1) Multiple domains: multiple instances of OPTION_S46_CONT_MAPE will be present.
> 
> (2) Single domain, multiple subnets: multiple instances of OPTION_S46_RULE will be present within a single instance of OPTION_S46_CONT_MAPE.
> 
> In either case, the correlation between the End-user IPv6 prefix and its corresponding Basic Mapping Rule is achieved through longest match. A good CPE implementation will validate that there is a 1-1 correspondence between the BMRs and the provisioned End-user IPv6 prefixes.
> 

yes, I believe so.
although for (2) multiple End-user IPv6 prefixes is independent of multiple rules. there will be exactly one BMR per MAP domain.

cheers,
Ole

---

From: Ian Farrer <[email-masked]>
Date: Fri, 25 Apr 2014 14:42:55 +0200

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