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

From: Ole Troan <[email-masked]>
Date: Fri, 10 May 2013 10:14:08 +0200

>  This message starts a two week softwire working group last call on
> advancing the draft about providing Mapping of Address and Port with
> Encapsulation 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-05.txt
> http://tools.ietf.org/html/draft-ietf-softwire-map-05
> 
> 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. The chairs will send in
> their comments as well during the last call period. This last call will
> conclude on April 9, 2013.

all,

apologies for the delay in dealing with the WGLC comments.
Tom has joined in on the editor team, and we have just posted a revision 06 that
should address the comments received.

see: 
http://tools.ietf.org/html/draft-ietf-softwire-map-06
http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-06

a summary of the WGLC below.

-------------------------------------

WGLC: March 26 - April 9

Cameron Byrne:
"Source Address / Port spoofing should be explicitly denied"

Action: Clarified spoofing rules. s/SHOULD/MUST:

      <t>A MAP CE receiving an IPv6 packet to its MAP IPv6 address
      sends this packet to the CE's MAP function where it is
      decapsulated. All other IPv6 traffic is forwarded as per the
      CE's IPv6 routing rules. The resulting IPv4 packet is then
      forwarded to the CE&rsquo;s NAT44 function where the destination
      port number MUST be checked against the stateful port mapping
      session table and the destination port number MUST be mapped to
      its original value.</t>

      <t>A MAP BR receiving IPv6 packets selects a best matching MAP
      domain rule based on a longest address match of the packets'
      source address against the BR's configured MAP BMR prefix(es),
      as well as a match of the packet destination address against the
      configured BR IPv6 address or FMR prefix(es). The selected MAP
      rule allows the BR to determine the EA-bits from the source IPv6
      address. The BR MUST perform a validation of the consistency of
      the source IPv6 address and source port number for the packet
      using BMR. If the packets source port number is found to be
      outside the range allowed for this CE and the BMR, the BR MUST
      drop the packet and respond with an ICMPv6 "Destination
      Unreachable, Source address failed ingress/egress policy" (Type
      1, Code 5).</t>

      <t>In order to prevent spoofing of IPv4 addresses, the MAP node
      MUST validate the embedded IPv4 source address of the
      encapsulated IPv6 packet with the IPv4 source address it is
      encapsulated by according to the parameters of the matching
      mapping rule. If the two source addresses do not match, the
      packet MUST be dropped and a counter incremented to indicate
      that a potential spoofing attack may be underway.  Additionally,
      a CE MUST allow forwarding of packets sourced by the configured
      BR IPv6 address.</t>

      <t>By default, the CE router MUST drop packets received on the
      MAP virtual interface (i.e., after decapsulation of IPv6) for
      IPv4 destinations not for its own IPv4 shared address, full IPv4
      address or IPv4 prefix.</t>

Nejc Škoberne <[email-masked]>

"Validity of the 5th example."
Action: While example is correct, clarified example by being explicit about PSID being provisioned by DHCP.
           Changed PSID to another value than the examples using EA bits.

"formula for calculating PSID (K) using a port P, ratio R, and M. It is very non-obvious"
Action: None.

Tom Taylor <[email-masked]>
In Section 5.2 of -map-05, there is the paragraph:

  "The MAP subnet ID is defined to be the first subnet (all bits set to
  zero).  Unless configured differently, a MAP node MUST reserve the
  first IPv6 prefix in an End-user IPv6 prefix for the purpose of MAP."

Action: Rewritten to:
        "The MAP subnet identifier is defined to be the first subnet (all
        bits set to zero)."

Section 5, bullet 1, Basic Mapping Rule:

I wonder if you might make it clear that the relationship between the BMR and End-User MAP IPv6 Prefix is N:1, like this:

"There can only be one Basic Mapping Rule per End-user IPv6 prefix (although multiple End-User IPv6 Prefixes may share the same Basic Mapping Rule, leading to provisioning efficiencies at the MAP BR)."

Action, added:

      <t>Basic Mapping Rule (BMR) - mandatory. A CE can be provisioned
      with multiple End-user IPv6 prefixes. There can only be one
      Basic Mapping Rule per End-user IPv6 prefix. Although all CE's
      having End-user IPv6 prefixes within (aggregated by) the same
      Rule IPv6 prefix may share the same Basic Mapping Rule. In
      combination with the End-user IPv6 prefix, the Basic Mapping
      Rule is used to derive the IPv4 prefix, address, or shared
      address and the PSID assigned to the CE.</t>

Section 5.1, Port mapping algorithm:

Relabel Figure 2 as follows:
   "Figure 2: Structure of a Port-Restricted Port Number"

Action: Accepted.

Put the definition of a before the definition of A. This makes the logic flow better.

Definition of A: add before what is there now: "Selects which range the port number lies in."

Definition of PSID: Add a third sentence: "This is guaranteed by the algorithm described here."

Definition of k-bits: typo s/k^2/2^k/

Action: Accepted.

Definition of M, replace present text with: "Selects the specific port within the particular range specified by the concatenation of A and the PSID."

Action: Accepted.

At the end, delete the duplicate sentence: "This algorithm ...contiguous ranges."

Action: Done.

Ian Farrer

"I have one comment about the current version: It is using an IPv4 default route as the method for sending traffic out of the MAP domain. This is likely to cause provisioning complexity and conflicts with two other related drafts:"

Action, rewrite section to:

      <section anchor="outside-domain" title="Destinations outside the MAP domain">
     <t>IPv4 traffic between MAP nodes that are all within one MAP
     domain is encapsulated in IPv6, with the senders MAP IPv6
     address as the IPv6 source address and the receiving MAP
     node's MAP IPv6 address as the IPv6 destination address. To
     reach IPv4 destinations outside of the MAP domain, traffic is
     also encapsulated in IPv6, but the destination IPv6 address is
     set to the configured IPv6 address of the MAP BR.</t>

        <t>On the CE, the path to the BR can be represented as a point
        to point IPv4 over IPv6 tunnel <xref target="RFC2473"/> with
        the source address of the tunnel being the CE's MAP IPv6
        address and the BR IPv6 address as the remote tunnel
        address. When MAP is enabled, a typical CE router will install
        a default route to the BR.</t>

     <t>The BR forwards traffic received from the outside to CE's
     using the normal MAP forwarding rules.</t>

      </section>

---

From: <[email-masked]>
Date: Sat, 11 May 2013 21:57:11 +0200

Hi Ole,

Thanks for incorporating  my comments into this version.

Having re-read this version, there's one thing that I'd like to clarify: Is the BMR still being proposed as the method for configuring all IPv4 information, even with the EA=0 case? Section 5.2 states:

A length of 0 means that no part of the IPv4 address or port is embedded in the address.

Which is OK, if a little ambiguous.

Then in example 4 in the Appendix, the BMR is provisioning the /32 IPv4 prefix for the client, i.e 1:! mode or 'Binding Mode' to use the Unified CPE terminology.

I thought that we were going to use the OPTION_MAP_BIND proposed in softwire-unified-cpe to tell a lw4o6 CPE, or a MAP CPE to provision the Binding Mode.

Cheers,
Ian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Freitag, 10. Mai 2013 10:14
To: Suresh Krishnan
Cc: Softwires WG; Yong Cui; Ralph Droms
Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-05

> 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. The chairs 
> will send in their comments as well during the last call period. This 
> last call will conclude on April 9, 2013.

all,

apologies for the delay in dealing with the WGLC comments.
Tom has joined in on the editor team, and we have just posted a revision 06 that should address the comments received.

see: 

WGLC: March 26 - April 9

Cameron Byrne:

Action: Rewritten to:

Action, added:

Action: Accepted.

Action: Accepted.

Action: Accepted.

Action: Done.

Ian Farrer

      </section>

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

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 May 2013 11:18:36 +0200

Ian,

> A length of 0 means that no part of the IPv4 address or port is embedded in the address.

yes. that's is the meaning of EA=0.

> Which is OK, if a little ambiguous.

how so?

> I thought that we were going to use the OPTION_MAP_BIND proposed in softwire-unified-cpe to tell a lw4o6 CPE, or a MAP CPE to provision the Binding Mode.

the MAP BMR isn't only a 'provisioning construct' it is also used for forwarding.
the MAP document doesn't say anything about how the BMR is provisioned.

if you created a separate DHCP option for the corner case of EA=0, how should a Rule IPv4 prefix length of 32 with EA=0, be handled?
seems like we then create more ambiguity...

cheers,
Ole

---

From: <[email-masked]>
Date: Mon, 13 May 2013 11:56:38 +0200

Hi Ole,

>> Having re-read this version, there's one thing that I'd like to
>>clarify: Is the BMR still being proposed as the method for configuring
>>all IPv4 information, even with the EA=0 case? Section 5.2 states:
>> 

[ian] The description says what it doesn't do without saying what it does
do. That's why I would say it's ambiguous.

>
>> Then in example 4 in the Appendix, the BMR is provisioning the /32 IPv4
>>prefix for the client, i.e 1:! mode or 'Binding Mode' to use the Unified
>>CPE terminology.
>> 
>> I thought that we were going to use the OPTION_MAP_BIND proposed in
>>softwire-unified-cpe to tell a lw4o6 CPE, or a MAP CPE to provision the
>>Binding Mode.
>
>if you created a separate DHCP option for the corner case of EA=0, how
>should a Rule IPv4 prefix length of 32 with EA=0, be handled?

[ian] As I proposed in Orlando (second to last slide):
http://www.ietf.org/proceedings/86/slides/slides-86-softwire-3.pdf

No objections were raised to this.

Cheers,
Ian

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 May 2013 12:21:30 +0200

Ian,

> do. That's why I would say it's ambiguous.

there was a lot of pushback from describing 1:1 mode in more detail in the MAP base
document.

> No objections were raised to this.

see section 7.
EA=0 and a configured Rule IPv4 prefix of /32 results in 1:1/binding mode.

_how_ that Rule IPv4 prefix is configured is out of scope of the base MAP document.

my previous comment was to the provisioning document, where I think it would be ambiguous to have two options
to do the same thing.

do you have any proposed changes to MAP base, or is this for the provisioning document?

cheers,
Ole

---

From: <[email-masked]>
Date: Mon, 13 May 2013 14:45:42 +0200

Hi Ole,

Comments in line.

Cheers,
Ian

>there was a lot of pushback from describing 1:1 mode in more detail in

[ian] I recall:-) As I said, I'm OK with what it says and the ambiguity is
not really a problem in it's own right. It'sl Ex 4 in the appendix where
it states that you provision v4 using BMR/FMR.

>_how_ that Rule IPv4 prefix is configured is out of scope of the base MAP

[ian] App. A ex 4 does state that the IPv4 config is taken from the
BMR/FMR and 5.2/5.3 state the parameters for constructing BMRs/FMRs.
Although it doesn't state how (as in the configuration method / protocol)
this is configured, the parameters are stated, even though many of them
are not required for 1:1.

>do you have any proposed changes to MAP base, or is this for the

[ian] I think that the simplest way to make all this work is together is
to separate out the BMR for mesh mode and the 1:1 mapping rule. As long as
the BMR is described as the mechanism for provisioning 1:1 mode, then the
additional configuration parameters of the BMR must also be conveyed (I.e.
all of the things that are detailed in section 5.2), even though many of
them are only relevant for mesh.

So, the change in the MAP base draft would be: if EA=0, then the IPv4
configuration / port set is not provisioned within the BMR and is conveyed
through another means (static, OPTION_MAP_BIND, DHCPv4 over DHCPv6 or
whatever). This gives us the single method of configuring MAP 1:1/lw4o6.

The MAP DHCP option draft then needs to be brought in line with this.

---

From: Ole Troan <[email-masked]>
Date: Mon, 13 May 2013 15:36:54 +0200

Ian,

> them are only relevant for mesh.

a BMR consists of 3 elements, a Rule IPv6 prefix, a Rule IPv4 prefix and the
EA bits length. only the Rule IPv6 prefix isn't relevant for 1:1.
if _that_ is a problem then each element could be suboptions in DHCP, but I'm not
sure that's worth the complexity either.

> whatever). This gives us the single method of configuring MAP 1:1/lw4o6.

creating another corner case that an implementation must take into regard.

a MAP node provisioned with no BMR and only OPTION_MAP_BIND could just map (sic)
the information in the OPTION_MAP_BIND into a BMR.

my argument is that this is a detail that can be taken care of in the MAP DHCP draft,
and that MAP base can still make the assumption that all its functions are done
based on the specified BMR/FMRs. there shouldn't be anything in MAP base
that forces a particular layout of the provisioning information.

> The MAP DHCP option draft then needs to be brought in line with this.

yes, the MAP DHCP draft must be updated no matter what.

cheers,
Ole

---

From: <[email-masked]>
Date: Wed, 15 May 2013 09:21:42 +0200

>sure that's worth the complexity either.

[ian] It could be one way of doing it, but having just looked at what a
'composite' set of sub-options would look like for this, it's going to get
pretty ugly.

>that forces a particular layout of the provisioning information.

[ian] I agree, but the way that the draft is at the moment, there is a
direct line between v4 provisioning with BMR/FMR, the parameters that
BMRs/FMRs contain and then (in the MAP DHCP draft) the format and
interpretation of the BMR/FMR.

If you remove the BMR/FMR provisioning in Ex. 4 and also sec 5.2 para 3,
then you've opened it up so that you don't force (or strongly imply) a
particular layout of the provisioning information.

---

From: Ole Troan <[email-masked]>
Date: Wed, 15 May 2013 11:17:05 +0200

Ian,

> 'composite' set of sub-options would look like for this, it's going to get

would think so.

> particular layout of the provisioning information.

many functions in MAP are based on the BMR/FMR those cannot be removed from the specification.
the mapping rules imply what needs to be provisioned, but it doesn't force a particular layout.

perhaps we should circle back and look at the provisioning options again, and see if that will
resolve this. if we end up with two provisioning options for the same thing, then there is no unification
at that level. of course a MAP implementation might take something like an OPTION_MAP_BIND and "map"
it into a BMR.

btw, with LW46/OPTION_MAP_BIND, how would an AFTR know which IPv6 source address the B4 uses?

cheers,
Ole