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

[<[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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

>  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 <[e-mail]>

"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 <[e-mail]>
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>

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