Subject: [Softwires] Document actions on MAP and 4rd

From: Suresh Krishnan <[email-masked]>
Date: Thu, 28 Jun 2012 11:16:13 -0400

Hi all,
  There has been quite a bit of traffic on the mailing list as to
whether the current map and 4rd drafts actually represent wg consensus.
In order to clear the air around this, we have asked the map and the 4rd
editors to revert to the revisions of the drafts that represent
consensus. Specifically

* map-01 will remove any descriptive text concerning the 1:1 mapping
rules from the -00 draft
* 4rd-02 will be identical to 4rd-u-06

The map-01 draft has been submitted and the 4rd-02 draft should be
submitted soon.

Thanks
Suresh

---

From: Rémi Després <[email-masked]>
Date: Thu, 28 Jun 2012 18:25:43 +0200

> * 4rd-02 will be identical to 4rd-u-06

Sorry, I couldn't see earlier the previous mail you sent me today. I was preparing my answer to it when I saw this mail on the list. (Sorry also if I misunderstood your intention when we talked, since I would have made then the comments below.)
 
1.
Replacing 4rd-01 by 4rd-u-06 (the pre-Paris document on 4rd) would have been be fair *ONLY IF* map-00 would have been replaced by pre-Paris documents on map (i.e. mdt-softwire-mapping-address-and-port-01, possibly accompanied by some or all of its companion drafts).

2.
Actually, neither map-00 nor 4rd-00 have been just renamed pre-Paris drafts: 
- map-00 is a completely restructured specification of map, also including some technical novelties. This raised AFAIK *no objection* from anyone (if on excludes the 1:1 issue, which was contentious WITHIN the map team.   
- 4rd-00 also differs from 4rd-u-06 (editorial improvements and one technical novelty, clearly announced to the WG in www.ietf.org/mail-archive/web/softwires/current/msg04256.html). This also raised AFAIK *no objection" from anyone.
- Then, after discussions of 4rd-00 on the WG mailing list, it appeared that the specification could be further improved regarding a security issue (maybe minor, but real). At this point I made the mistake to issue 4rd-01, with this improvement, BEFORE asking for WG approval. Joel Halpern kindly warned me about the procedure infringement, which I acknowledged on the list. 

=> fairness can then be restored if I post a 4rd-02 identical to 4rd-00, thus relegating 4rd-01 to what it should have been, a proposal only submitted by its authors.

Hoping this is acceptable, I wait for your answer before doing anything.

Thank you,
RD

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

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 29 Jun 2012 03:40:33 +0000

Hi, Dear chairman

> * map-01 will remove any descriptive text concerning the 1:1 mapping

In MAP-00, the editors combined MAP-T and MAP-E together (which is only combined by words, they are still two solutions that carriers have to choose one). 
In my memory, this has not been discussed openly, neither reach WG consensus. 
So, may I venture to suggest this issue also backwarded to the original for discussion?

B.R.
Bing

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Suresh Krishnan
Sent: Thursday, June 28, 2012 11:16 PM
To: Softwires WG
Subject: [Softwires] Document actions on MAP and 4rd

Hi all,

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 29 Jun 2012 08:24:46 -0400

Hi Remi,

> Hoping this is acceptable, I wait for your answer before doing anything.

No problems. Go ahead and submit the -02 identical to -00. We can handle any further issues using the issue tracker. 

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 29 Jun 2012 08:34:51 -0400

Hi Bing,
  For the sake of progress, we cannot keep revisiting our decisions forever. The map-01 document is now under working group change control. I think the best way forward is to file this as an issue in the issue tracker and see what the wg thinks about this. 

Thanks
Suresh

________________________________________
From: Liubing (Leo) [[email-masked]]
Sent: Thursday, June 28, 2012 11:40 PM
To: Suresh Krishnan; Softwires WG
Subject: RE: [Softwires] Document actions on MAP and 4rd

Hi, Dear chairman

B.R.
Bing

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Suresh Krishnan
Sent: Thursday, June 28, 2012 11:16 PM
To: Softwires WG
Subject: [Softwires] Document actions on MAP and 4rd

Hi all,

Thanks
Suresh

---

From: Rémi Després <[email-masked]>
Date: Sat, 30 Jun 2012 10:35:10 +0200

Dear all,

1.
2012-06-29 à 14:24, Suresh Krishnan:
...
> submit the -02 identical to -00.

Done with tools.ietf.org/html/draft-ietf-softwire-4rd-02 

> We can handle any further issues using the issue tracker. 

Will learn how to do it.

2.
Please take the copied email below and tools.ietf.org/html/draft-ietf-softwire-4rd-01 as:
- identification of a possible security improvement of 4rd from 4rd-02
- description of the solution, presented as an update of the draft combined with some editorial improvements.)

Authors propose to the WG to update -02 by a re-issue of -01 as -03.
Any objection?

Regards,
RD

> De : Rémi Després <[email-masked]>
> Date : 2012-06-19 15:28
> À : Softwires WG <[email-masked]>
> Objet : Novelty in draft-ietf-softwire-4rd-01
> 
> Dear all,
> 
> The main difference between -00 and -O1 concerns protection against address or protocol corruption during 4rd-domain traversal:
> Problem: the CNP only protected IPv4 addresses of full-or-shared-address CEs? In particular, they didn't protect IPv4 addresses embedded in BR-destined IPv6 addresses (an overlook) 
> Solution: include a checksum of IPv4 addresses and protocol in the flow label field 
>  . It provides the desirable protection in a simple and intuitive way
>  . It remains compatible with the flow-label specification (see below)
> 
> 
> Relationship with FLs of RFC6437 is analyzed as follows:
> 
> a) RFC6437 says "A node that forwards a flow whose flow label value in arriving packets is zero MAY change the flow label value.  In that case, it is RECOMMENDED that the forwarding node sets the flow label field for a flow to a uniformly distributed value as just described for source nodes. ... In such cases, a flow can be defined by fewer IPv6 header fields, typically using only the 2-tuple {dest addr, source addr}."
> 
> b) In CEs and BRs, arriving packets are IPv4, i.e. equivalent to packets without FLs. 
> 
> c) In RFC2119, "RECOMMENDED" means that "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course".
> 
> d) Implications, which have been well understood, have also been well weighted:
> - With this, FLs of 5-tuple flows aren't evenly distributed FLs, contrary to what is recommended
> - BUT this maintains IPv4 addresses-and-port protection without needing any extra header between the IPv6 header and the unchanged IP payload, a desirable feature of 4rd. 
> 
> Comments on all aspects of the proposal are welcome.
> 
> Regards,
> RD