Subject: [Softwires] MAP-T DMR and IPv4 address mapping

From: Wojciech Dec <[email-masked]>
Date: Thu, 6 Jun 2013 15:23:09 +0200

Hello All,

would like to get your feedback regarding a possible change to the way IPv4
addresses are mapped into the MAP-T DMR prefix. The current text,
http://tools.ietf.org/html/draft-ietf-softwire-map-t-01#section-5.4 ,
follows RFC6052, and sees the IPv4 address inserted after the prefix. This
aligns naturally with any/all existing NAT64 implementations, i.e. in a
non-shared-address domain, a MAP-T CE would work with any regular NAT64 BR.
A direct consequence of following RFC6052 is that, in cases where the
prefix is shorter than /64, it results in some "bit spreading" of the IPv4
address across the u-byte. See http://tools.ietf.org/html/rfc6052#page-5.
This is likely to be cumbersome operationally.

An option for simplifying this, and the change proposal seeking your
feedback, would be to specify that the DMR should be a /64 prefix, or at
least to make a recommendation to that effect in the specification.

Feedback?

Regards,
Woj.

---

From: Ole Troan <[email-masked]>
Date: Thu, 6 Jun 2013 15:28:00 +0200

> would like to get your feedback regarding a possible change to the way IPv4 addresses are mapped into the MAP-T DMR prefix. The current text, http://tools.ietf.org/html/draft-ietf-softwire-map-t-01#section-5.4 , follows RFC6052, and sees the IPv4 address inserted after the prefix. This aligns naturally with any/all existing NAT64 implementations, i.e. in a non-shared-address domain, a MAP-T CE would work with any regular NAT64 BR. 
> A direct consequence of following RFC6052 is that, in cases where the prefix is shorter than /64, it results in some "bit spreading" of the IPv4 address across the u-byte. See http://tools.ietf.org/html/rfc6052#page-5. This is likely to be cumbersome operationally.
> 
> An option for simplifying this, and the change proposal seeking your feedback, would be to specify that the DMR should be a /64 prefix, or at least to make a recommendation to that effect in the specification.

given that 6man is removing the special meaning of the U/G bits, perhaps RFC6052 should be updated, and MAP-T could ignore the U-byte?

cheers,
Ole

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 6 Jun 2013 13:33:16 +0000

It would be reasonable to state it as a recommendation (unless U-octet gets changed by 6man*), since it is advantageous to be able to find the encoded IPv4 address relatively easily during troubleshooting.

* We wouldn't want to wait for that change to happen as a normative reference.

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ole Troan
> Sent: Thursday, June 06, 2013 9:28 AM
> To: Wojciech Dec
> Cc: Softwires-wg; Congxiao Bao
> Subject: Re: [Softwires] MAP-T DMR and IPv4 address mapping
> 
> > would like to get your feedback regarding a possible change to the way
> IPv4 addresses are mapped into the MAP-T DMR prefix. The current text,
> http://tools.ietf.org/html/draft-ietf-softwire-map-t-01#section-5.4 , follows
> RFC6052, and sees the IPv4 address inserted after the prefix. This aligns
> naturally with any/all existing NAT64 implementations, i.e. in a non-shared-
> address domain, a MAP-T CE would work with any regular NAT64 BR.
> given that 6man is removing the special meaning of the U/G bits, perhaps
> RFC6052 should be updated, and MAP-T could ignore the U-byte?
> 
> cheers,
> Ole
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Thu, 6 Jun 2013 14:58:06 +0000

I think that would be a great idea to update rfc 6052 to ignore the u
byte. It has been a pain to code, debug and maintain with bits spraying
across this artificial boundary.
That would naturally help MAP-T draft as well.

Thanks
Senthil

On 6/6/13 9:28 AM, "Ole Troan" <[email-masked]> wrote:

>>follows RFC6052, and sees the IPv4 address inserted after the prefix.
>>This aligns naturally with any/all existing NAT64 implementations, i.e.
>>in a non-shared-address domain, a MAP-T CE would work with any regular
>>NAT64 BR. 
>>prefix is shorter than /64, it results in some "bit spreading" of the
>>IPv4 address across the u-byte. See
>>http://tools.ietf.org/html/rfc6052#page-5. This is likely to be
>>cumbersome operationally.
>>

---

From: Congxiao Bao <[email-masked]>
Date: Sat, 8 Jun 2013 13:25:27 +0800

I would like suggest:
1. Let  /64 be the default for DMR;
2. Keep U-byte in the current MAP-T document, referred to RFC6052;
3. RFC 6052 should be updated aligning the outcome  of 6man.

Regards,
Congxiao

2013/6/6 Rajiv Asati (rajiva) <[email-masked]>

> It would be reasonable to state it as a recommendation (unless U-octet
> gets changed by 6man*), since it is advantageous to be able to find the
> encoded IPv4 address relatively easily during troubleshooting.
>
> follows
> IPv4

---

From: Simon Perreault <[email-masked]>
Date: Mon, 10 Jun 2013 15:23:03 +0200

> across this artificial boundary.

+1

Same experience here.

Simon