Subject: Re: [Softwires] Comments on draft-ietf-softwire-map-02.txt

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 13 Sep 2012 13:31:10 -0500

Hi Woj,

I have some comments on this draft.

Regarding Section 5, I am curious why we need the mapping, i.e.
Section 5 if we are doing MAP-E? i.e. NAT44'ed IPv4 packet is
encapsulated in IPv6 using RFC 2473. RFC2473 defines quite in detail
in Section 5 on Tunnel IPv6 Header almost everything needed.

More specific comments: what is the relationship of this draft with
the original MAP-E draft, draft-mdt-softwire-map-encapsulation-00?
That draft described in detail how RFC 2473 would be used which is
missing in draft-ietf-softwire-map-02. OTOH draft-ietf-softwire-map-02
does not even reference draft-mdt-softwire-map-encapsulation-00, why?

Regards,

Behcet

On Wed, Sep 5, 2012 at 3:10 AM,  <[email-masked]> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Softwires Working Group of the IETF.
>
>         Title           : Mapping of Address and Port with Encapsulation (MAP)
>         Author(s)       : Ole Troan
>                           Wojciech Dec
>                           Xing Li
>                           Congxiao Bao
>                           Satoru Matsushima
>                           Tetsuya Murakami
>         Filename        : draft-ietf-softwire-map-02.txt
>         Pages           : 29
>         Date            : 2012-09-05
>
> Abstract:
>    This document describes a mechanism for transporting IPv4 packets
>    across an IPv6 network, and a generic mechanism for mapping between
>    IPv6 addresses and IPv4 addresses and transport layer ports.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-map
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-softwire-map-02
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-02
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Ole Trøan <[email-masked]>
Date: Fri, 14 Sep 2012 09:36:19 +0200

Bechet,

> in Section 5 on Tunnel IPv6 Header almost everything needed.

MAP-E does everything MAP does. support of mesh mode, stateless BRs...
without mapping how would that be achieved?

> does not even reference draft-mdt-softwire-map-encapsulation-00, why?

draft-ietf-softwire-map has evolved from draft-mdt-softwire-map-encapsulation and is meant
to incorporate all the significant parts of it. something may have fallen out in editing,
if so please propose text.

cheers,
Ole

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 14 Sep 2012 10:49:03 -0500

Ole,
Thanks for your quick reply.
Please see inline.

> without mapping how would that be achieved?

Well, this is very well answered in draft-mdt-softwire-map-encapsulation-00
Section 8.2 which says that

all CEs do not look up the mapping rules upon receiving an
   IPv4 packet from its LAN side and then CE must encapsulate the IPv4
   packet with IPv6 whose destination must be a given BR.

referring to the Hub & Spoke model.

Do we have a similar statement in draft-ietf-softwire-map-02?
I think we should.

> if so please propose text.

draft-mdt-softwire-map-encapsulation gives details of many things
including encapsulation and fragmentation referring to specific
section of RFC 2473. I think we should carry these important details
to the new and normative draft?

One more issue:

Regarding Section 7.2 which states that BR MUST use this anycast IPv6
address as the source
   address in packets relayed to CEs.
It seems like this has been carried over from 6rd.

I have concerns on this MUST. I think that CE has to maintain multiple
tunnel interfaces with BRs if there are more than one BR, right? How
would this be possible if CE does not know the unicast address of BR?

Also, at times, MAP-E could be stateful. This is explained in Section
7 of draft-mdt-softwire-map-encapsulation which you do not not have.
How could CE identify the specific BR in this case?

I suggest changing MUST to MAY or even removing that sentence.

Regards,

Behcet

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 19 Sep 2012 19:24:17 +0900

Hi Behcet,

> Do we have a similar statement in draft-ietf-softwire-map-02?

It looks that there're two cases for hub-and-spoke mode. One is that a CE forwards packets with MRT as same as mesh mode, but it has only DMR. The other is that a CE forwards all packets with following DMR even it has several FMRs. Do we need to distinguish each of them? then write up both cases for hub-and-spoke?

> to the new and normative draft?

Would you suggest which text should be carried out from previous MAP-E?

> I suggest changing MUST to MAY or even removing that sentence.

It looks you suggest the case which supports multiple DMRs on a CE. Is that correct understanding? On the CE, the source address of a received IPv6 packet MUST be the BR address of the DMR(s) which the CE has.

cheers,
--satoru

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 19 Sep 2012 11:05:14 -0500

HI Satoru,

I am saying that hub & spoke model is quite simple in case of MAP-E.
In the draft, draft-ietf-softwire-map-02, as you have done it in
draft-mdt-softwire-map-encapsulation-00, specify hub&spoke case first.

I know that mesh model is important for MAP-E as BR may be deployed
deep in the network. You are explaining in detail in Section 5. I
suggest adding one clarifying statement saying that it applies to the
mesh model.

As for the details of encapsulation in reference to
draft-mdt-softwire-map-encapsulation-00, I suggest that you

either make draft-mdt-softwire-map-encapsulation-00 a normative
reference and make it up to date, or

add some details to draft-ietf-softwire-map-02 on how the
encapsulation in MAP-E works in reference to RFC 2473.

As for the source address of IPv6 packets sent by BR, I suggest
removing the requirement to make it an anycast address. I read in a
vendor web site (Cisco) it is stated that anycast addresses must not
be used as source addresses. RFC 4291 does not require this though.

The reason? As I explained, at times MAP-E is stateful, how would CE
find the right BR if it does not know BR's unicast address?

I hope the above is clear. I am removing the conversation we had
before, but I am curious, what is MRT? I could not find it anywhere?

Regards,

Behcet