Subject: [Softwires] MAP Open issues: Interface-id

From: Ole Troan <[email-masked]>
Date: Fri, 4 Nov 2011 14:45:22 +0100

all,

what should the interface-id in MAP IPv6 addresses be?
the interface-id is used both for creating a local source address, and for mapping an IPv4 address + port into an IPv6 destination address.

requirements:
 - MUST be possible for CE's in the domain to calculate with an algorithm based on destination IPv4 address + port
 - MUST encode the destination IPv4 address for out of domain traffic (for translation)
 - MUST be possible to use to configure an IPv6 address on the MAP node
 - MAY be globally unique
 - SHOULD be simple to read (by human or machine) for troubleshooting

possibilities:
1) RFC6052
2) IANA-ish:
   Not globally unique:
                  |   32 bits        |    32 bits       |
                  +------------------+------------------+
                  | 00-00-5E-FE      |  IPv4 address    |
                  +------------------+------------------+
3) IANA type:

   Globally unique, with max sharing ratio of 256:

                  |   24 bits  |    32 bits     | 8 bits|
                  +------------+----------------+-------+
                  | 02-00-5E-FE|  IPv4 address  | PSID  |
                  +------------+----------------+-------+

4)
   Globally unique with "Length" field to allow parsing of interface id (in case of full IPv4 address or IPv4 prefix)

                  <-8-><-------- L>=32 -------><48-L><8->
                  +---+----------------+------+-----+---+
                  | u |  IPv4 address  | PSID |  0  | L |
                  +---+----------------+------+-----+---+

5) New IANA assigned with V flag to allow 'identification' of MAP traffic versus native:

                  <-8-><-------- L>=32 -------><48-L><8->
                  +---+----------------+------+-----+---+
                  | V |  IPv4 address  | PSID |  0  | L |
                  +---+----------------+------+-----+---+

6) Right aligned:

                  <-8-><--0-16->     < 5><--  32  ------>
                  +---+--------+----+---+---------------+
                  | u |  PSID  | 0  | L | IPv4 address  |
                  +---+--------+----+---+---------------+

---

From: jouni korhonen <[email-masked]>
Date: Fri, 4 Nov 2011 16:29:39 +0200

Ole,

>                  |   24 bits  |    32 bits     | 8 bits|

This is not quite possible.. 02-00-5E-FE is 32 bits not 24, right.

- Jouni

---

From: Ole Troan <[email-masked]>
Date: Fri, 4 Nov 2011 15:34:34 +0100

Jouni,

> This is not quite possible.. 02-00-5E-FE is 32 bits not 24, right.

indeed. it should really be 02-00-5E + IPv4 address + PSID

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Mon, 7 Nov 2011 10:46:49 +0100

Ole,

1. Checksum neutrality being an open question, it is relevant here.
2. It is useful AFAIK to distinguish CE addresses from BR addresses.

The best proposal I know so far is as follows (with CNP = Checksum neutrality preserver) 

CE ADDRESS

<- - - - - - IPv6 Unformatted  address (104 bits) - - - ->
+-------------------+----------+----------+---------------+
| Rule IPv6 prefix  |IPv4 suff.| Max PSID |  Padding = 0  |
+-------------------+----------+----------+---------------+
:
:<- - - - - - - - - 64  - - - - - >:<- - - - 40 - - - - ->:
:                                  :\                      \ 
:                                  <8>                      :<- 16 ->
:                                  : :                      :        :
+----------------------------------'-'----------------------+--------+
| IPv6 unformatted address (part 1)|V|                      |   CNP  |        
+----------------------------------+-+----------------------+--------+
<- - - - - - - - - - -  IPv6 address (108 bits)  - - - - - - - - - - >                

BR ADDRESS

+------------------------------------+-+-----------------+-+-------+
|              BR IPv6 prefix        |V|   IPv4 address  |0|  CNP  |
+------------------------------------+-+-----------------+-+-------+
< - - - - - - - - - 64  - - - - - - ><8><- - -  32 - - -><8><  16  > 

Cheers,
RD

Le 4 nov. 2011 à 14:45, Ole Troan a écrit :

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

---

From: GangChen <[email-masked]>
Date: Tue, 8 Nov 2011 16:34:45 +0800

> <- - - - - - IPv6 Unformatted  address (104 bits) - - - ->

+1
The checksum neutrality is desirable for translation case.
I suggest to take above format into consideration

BRs

Gang

---

From: Ole Troan <[email-masked]>
Date: Tue, 8 Nov 2011 09:36:50 +0100

> I suggest to take above format into consideration

the consequence of that is that the destination IPv6 address will change for every flow.
the MAP node cannot any longer listen to a single IPv6 address for MAP traffic, but has to intercept packets for a whole prefix.

cheers,
Ole

---

From: GangChen <[email-masked]>
Date: Tue, 8 Nov 2011 17:08:50 +0800

2011/11/8, Ole Troan <[email-masked]>:
> the MAP node cannot any longer listen to a single IPv6 address for MAP
> traffic, but has to intercept packets for a whole prefix.

Yes. I see there are two choices when MAP nodes process incoming packages
i) Should we let MAP node interface bind to a single static IPv6 address
ii) Should we let MAP node interface bind to a route to
IPv4-translatable IPv6 prefix

In translation case, above two cases are possible. That is
implementation specific. So I suggest to put above design as int-id
candidate for more inputs from the community

BRs

Gang

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 Nov 2011 10:12:32 +0100

> the consequence of that is that the destination IPv6 address will change for every flow.

If a source ignores the destination PSID length, yes, IPv6 addresses of two flows going to the same CE may differ.
But so what?
- The IPv4 packet submitted to the CE NAT is the same as the source IPv4 packet
- The final destinations behind the NAT may differ too

> the MAP node cannot any longer listen to a single IPv6 address for MAP traffic, but has to intercept packets for a whole prefix.

- BR's of double translation have always had this property.
- Talking with Mark townsley, I got the understanding that this wasn't a real problem, at least with IOS.
=> Clarifying this point would IMHO be useful. 

Cheers,
RD

---

From: Ole Troan <[email-masked]>
Date: Tue, 8 Nov 2011 10:17:50 +0100

> - Talking with Mark townsley, I got the understanding that this wasn't a real problem, at least with IOS.

everything can be _implemented_, that's not the point.

> => Clarifying this point would IMHO be useful. 

it is clearly requiring bigger changes to tunnel code. which unlike NAT code is attached to 'one' endpoint.
it makes co-existence of a MAP endpoint and native IPv6 nodes within a single /64 much harder.

let us turn this around. what's the point in embedding a new set of CNP bits in the IPv6 address, when the L4 checksum can be incrementally updated. that's what everyone has existing code to do already...

cheers,
Ole

---

From: jouni korhonen <[email-masked]>
Date: Tue, 8 Nov 2011 11:22:29 +0200

On Nov 8, 2011, at 11:17 AM, Ole Troan wrote:

[snip]

> let us turn this around. what's the point in embedding a new set of CNP bits in the IPv6 address, when the L4 checksum can be incrementally updated. that's what everyone has existing code to do alr…

I definitely agree with Ole here.

- Jouni

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 Nov 2011 11:34:44 +0100

> everything can be _implemented_, that's not the point.

The point you made in the past against this capability was that it was difficult, if not even impossible, with the _current_ IOS.
If it is easy, we can focus the discussion on functional considerations (see below).

> it makes co-existence of a MAP endpoint and native IPv6 nodes within a single /64 much harder.

Hopefully, there will be implementers in Taipei to clarify this subject.
Still in serious doubt about "big changes".

> let us turn this around. what's the point in embedding a new set of CNP bits in the IPv6 address, when the L4 checksum can be incrementally updated. that's what everyone has existing code to do alr…

Before answering this (good) question, let's make clear that the code to add or subtract a few 16-bit fields is always trivial. This doesn't depend on whether it applies to a field in the IP payload or in an IPv6 address.

Now, the difference, already explained in the context of 4rd-U, is between a Reversible Header Mapping (nothing done to the IP payload), and a translation that involves transport-layer considerations (checksum adjustment for specific transport protocols): 

IPv4 packet   Reversible Header mapping   IPv6 packet
+-----------------+ _           _ +-----------------+
|   IPv4 Header   | _| <---->  |  |  IPv6 Header    |
+-----------------+            |  +-----------------+
|     IP Data     |            |_ |IPv6 Frag. Header|
+-----------------+               +-----------------+
                                  |     IP Data     |
                                  +-----------------+

               Translation per RFC 6145
+-----------------+ _           _ +-----------------+
|   IPv4 Header   | _|  ---->  |  |  IPv6 Header    |
+-----------------+ _          |  +-----------------+
|Transport Header | _|  -.     |_ |IPv6 Frag. Header| (if needed)
+-----------------+       \     _ +-----------------+
| Transport Data  |        '-> |_ |Transport Header | (adjusted checksum
+-----------------+               +-----------------+   if needed)
                                  |  Transport Data |
                                  +-----------------+
          (not transparent to IPv4 DF bit)

Cheers,
RD

---

From: Mark Townsley <[email-masked]>
Date: Tue, 8 Nov 2011 11:35:38 +0100

> => Clarifying this point would IMHO be useful. 

Our tunnel code typically processes tunnel packets upon receipt at a single address  (/128 for v6 or /32 for v4). This is by far the easier and more "normal" way of doing things for the myriad of tunnels we support today. Implementing on receipt of anything other than an address (or hostroute, if your prefer since this is a router) is "possible" but would certainly be considered "special" and as such has a higher bar for implementation within the typical tunneling architecture (at least in the implementations I am aware of, YMMV).

Apologies if I was not clear on this point when we talked the other day. 

- Mark

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 Nov 2011 11:55:56 +0100

> Apologies if I was not clear on this point when we talked the other day. 

Apologies if I took what you said more positively (IMHO) than what you wanted to express.

I am still curious to see how NAT64 is implemented, including in open-source code.
However, I am fine with leaving aside for the time being this question of code complexity (as you say subject to YMMV), and with focusing on what operational features depend on this capability.  

Cheers,
RD

---

From: Jacni Qin <[email-masked]>
Date: Thu, 10 Nov 2011 15:24:34 +0800

hi,

On 11/8/2011 5:08 PM, GangChen wrote:
> ...
Well, by an interface-id for MAP, works.
> IPv4-translatable IPv6 prefix
This is what I ever proposed, a new interpretation of the V/U octet, 
forming a specific route, say /72 pointing to the MAP function.

> candidate for more inputs from the community
But the variable destination addresses to target MAP function makes the 
above impossible. We can't ignore this issue during the MAP design.

Cheers,
Jacni

---

From: Jacni Qin <[email-masked]>
Date: Thu, 10 Nov 2011 15:27:21 +0800

hi,

> it makes co-existence of a MAP endpoint and native IPv6 nodes within a single /64 much harder.
+ 1

Cheers,
Jacni