Subject: [Softwires] Limiting the length of the MAP endpoint IPv6 prefix

From: Tom Taylor <[email-masked]>
Date: Sun, 27 Jan 2013 17:07:48 -0500

The examples in my previous note sort of provided backing for my view 
that the MAP endpoint IPv6 prefix can be limited to a maximum of a /64, 
thus making the IID fully conformant both to RFC 4291 and to RFC 6052.

Obviously, the more IPv4 address bits you can stick into the EA bits, 
the fewer the number of MAP rules you have to provision. The picture of 
a MAP endpoint IPv6 prefix can be drawn like this:

+-----------------------------+-------------------+-----------+
|   Rule IPv6 prefix          |    IPv4 suffix    |    PSID   |
+-----------------------------+-------------------+-----------+
|                             |                   |           |
|  Common to all CEs sharing  | Common to all CEs | Unique to |
|     the same BMR            | sharing the same  |  this CE  |
|                             | IPv4 address      |           |

If we expect a Rule IPv6 prefix to be a /48 and a PSID to be no more 
than 8 bits in length (i.e. CEs get 512 ports each, sharing ratio is 
128), limiting the endpoint IPv6 prefix to 64 bits leaves room for eight 
bits of suffix. That in turn means each mapping rule serves 16384 CEs. 
If the Rule IPv6 prefix backs off to a /40, we can get two million CEs 
per mapping rule.

I think limiting the prefix length to 64 bits is reasonable. Comments?

Tom Taylor

---

From: Rémi Després <[email-masked]>
Date: Mon, 28 Jan 2013 09:43:03 +0100

Le 2013-01-27 à 23:07, Tom Taylor <[email-masked]> a écrit :

> The examples in my previous note sort of provided backing for my view that the MAP endpoint IPv6 prefix can be limited to a maximum of a /64, thus making the IID fully conformant both to RFC 4291 and to RFC 6052.
> 
> Obviously, the more IPv4 address bits you can stick into the EA bits, the fewer the number of MAP rules you have to provision. The picture of a MAP endpoint IPv6 prefix can be drawn like this:
> 
> 
> If we expect a Rule IPv6 prefix to be a /48 and a PSID to be no more than 8 bits in length (i.e. CEs get 512 ports each, sharing ratio is 128), limiting the endpoint IPv6 prefix to 64 bits leaves room for eight bits of suffix. That in turn means each mapping rule serves 16384 CEs. If the Rule IPv6 prefix backs off to a /40, we can get two million CEs per mapping rule.

> I think limiting the prefix length to 64 bits is reasonable. Comments?

+1
RD

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

---

From: Ole Troan <[email-masked]>
Date: Mon, 28 Jan 2013 10:26:16 +0100

Tom,

> Obviously, the more IPv4 address bits you can stick into the EA bits, the fewer the number of MAP rules you have to provision. The picture of a MAP endpoint IPv6 prefix can be drawn like this:

I don't think that's reasonable.
and I don't see what it buys us, given that supporting prefix lengths longer than 64 is simple.
IPv6 isn't classfull, there isn't anything magic with the 64 boundary. ;-)

cheers,
Ole

---

From: Tom Taylor <[email-masked]>
Date: Mon, 28 Jan 2013 08:49:52 -0500

>> The examples in my previous note sort of provided backing for my view that the MAP endpoint IPv6 prefix can be limited to a maximum of a /64, thus making the IID fully conformant both to RFC 4291…
...

> IPv6 isn't classfull, there isn't anything magic with the 64 boundary. ;-)

OK, then I agree with Rémi. Drop mention of prefixes greater than 64 
bits long and leave it to the reader to judge whether RFC 4291 imposes a 
limit.

Tom

---

From: Ole Troan <[email-masked]>
Date: Mon, 28 Jan 2013 14:59:48 +0100

> OK, then I agree with Rémi. Drop mention of prefixes greater than 64 bits long and leave it to the reader to judge whether RFC 4291 imposes a limit.

you want this removed:
      <t>If the End-user IPv6 prefix length is larger than 64, the most
      significant parts of the interface identifier is overwritten by the
      prefix.</t>

I disagree. this is the only text in there suggesting to an implementor that prefix lengths can be any value between 0-128.

Tom, Remi and I have stated our opinions. does anyone else have a view on the matter?

cheers,
Ole

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 28 Jan 2013 14:23:15 +0000

Let's not leave anything in the drafts as loose-ends for the readers (e.g. Implementors, designers, architects) to (mis)interpret. 

We better provide recommendations, if/as needed in case of ambiguity or disagreement.

IMO, /64 (or less) usage for end-user prefix is better off as a MAP (-E) recommendation, but not as an enforcement.  

Cheers,
Rajiv

Sent from my Phone

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Mon, 28 Jan 2013 14:24:19 +0000

I believe the prefix length > 64 should be allowed. It is upto the
operator to choose the prefix length of their choice.

On 1/28/13 8:59 AM, "Ole Troan" <[email-masked]> wrote:

>>>>that the MAP endpoint IPv6 prefix can be limited to a maximum of a
>>>>/64, thus making the IID fully conformant both to RFC 4291 and to RFC
>>>>6052.
>>>> 
>> ...
>> 
>>>> 
>I disagree. this is the only text in there suggesting to an implementor
>that prefix lengths can be any value between 0-128.
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 28 Jan 2013 17:16:32 +0100

Senthil,

2013-01-2815:24, Senthil Sivakumar (ssenthil) <[email-masked]>  :

> I believe the prefix length > 64 should be allowed.

> It is upto the

Agreed.
No one suggest to say the contrary.

Yet, operators have the constraint of RFC 4291 that "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format".  

The draft says that:
(a) The PSID is:
+--+---+---+---+---+---+---+---+---+
|PL|   8  16  24  32  40  48  56   |
+--+---+---+---+---+---+---+---+---+
|64| u | IPv4 address  |  PSID | 0 |
+--+---+---+---+---+---+---+---+---+
(b) "If the End-user IPv6 prefix length is larger than 64, the most significant parts of the interface identifier is overwritten by the prefix."

This is particularly unclear:
- What happens to the u octet?
- And to the IPv4 address if the prefix is longer than /68? 
- ...

Of course, if a use case is provided where MAP-E would be actually used with an IID shorter than 64 bits, it should be discussed. But:
- There is no such use case so far. 
- Looking for one doesn't seem useful. 

Regards,
RD

---

From: Ole Troan <[email-masked]>
Date: Mon, 28 Jan 2013 17:30:44 +0100

Remi,

> Yet, operators have the constraint of RFC 4291 that "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructe…

I am not aware of any implementations that restrict the prefix length to 64.
I'm not aware of any implementation that applies any meaning to any bits in the interface-id.
I'm aware of operators using prefix lengths longer than /64.

actual deployment and implementation trumps text. that doesn't even use RFC2119 language.
(and I know after annual discussions with one of the authors that the intention with that line was not to make IPv6 classful.)

> (a) The PSID is:

that's up to the operator.

> - And to the IPv4 address if the prefix is longer than /68? 

it gets overwritten by the prefix, isn't that what the text says?

> - Looking for one doesn't seem useful. 

huh?
provider wants to deploy with a prefix length of 128? single tunnel end point address. isn't that obvious?

cheers,
Ole

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Mon, 28 Jan 2013 16:36:35 +0000

Hi Remi,

On 1/28/13 11:16 AM, "Rémi Després" <[email-masked]> wrote:

>Yet, operators have the constraint of RFC 4291 that "For all unicast
>addresses, except those that start with the binary value 000, Interface
>IDs are required to be 64 bits long and to be constructed in Modified
>EUI-64 format".  

Honestly, I don¹t know the rationale behind this.

>(a) The PSID is:

I believe this figure is misleading by placing the IPv4 address in a fixed
location. Figure 3 and Figure 7
In the draft shows that the IID is not in a fixed location. Also, the text
surrounding the above figure 8, says
"The Interface identifier format of a MAP node is based on the format
   specified in section 2.2 of [RFC6052], with the added PSID field if
   present, as shown in figure Figure 8."

But RFC 6052 doesn¹t have the IPv4 address in a fixed location as per
section 2.2. So I think this figure is misleading.

|     n bits         |  o bits   | s bits  |   128-n-o-s bits      |
   +--------------------+-----------+---------+------------+----------+
   |  Rule IPv6 prefix  |  EA bits  |subnet ID|     interface ID      |
   +--------------------+-----------+---------+-----------------------+

>(b) "If the End-user IPv6 prefix length is larger than 64, the most
>prefix."

True.
>- What happens to the u octet?

I guess that needs to be made clear in the draft. We struggled with that
in our implementation.

>Of course, if a use case is provided where MAP-E would be actually used
>with an IID shorter than 64 bits, it should be discussed. But:

I would like to see the IPv4 address be present from bits 96-127, no need
for the PSID to be repeated again. That would allow us to go upto /96 and
being consistent with RFC 6052 which allows one to configure a prefix of
upto /96.

Thanks
Senthil

>>>>> IPv6 isn't classfull, there isn't anything magic with the 64
>>>>>boundary.
>>>>> ;-)
>>>>> 
>>>>> cheers,
>>>>> Ole
>>>>> 
>>>> 
>>> Tom, Remi and I have stated our opinions. does anyone else have a view
>>>on
>>> the matter?
>>> 
>>> cheers,
>>> Ole

---

From: Rémi Després <[email-masked]>
Date: Mon, 28 Jan 2013 17:57:18 +0100

> it gets overwritten by the prefix, isn't that what the text says?

Partially overwritten, yes, thus creating confusion, for no known reason to justify it.
I wonder what use of the IPv4 address could one imagine in this case?

> provider wants to deploy with a prefix length of 128? single tunnel end point address. isn't that obvious?

Obvious, no!

Could you please complete an example with a CE address and its BMR?

Thanks,
RD

---

From: Ole Troan <[email-masked]>
Date: Mon, 28 Jan 2013 18:48:26 +0100

Remi,

[...]

> I wonder what use of the IPv4 address could one imagine in this case?

no, fully overwritten.

> Could you please complete an example with a CE address and its BMR?

BMR:
Rule IPv6 prefix: 2001:db8::1/128
Rule IPv4 prefix: 1.1.1.1/32
EA-bits length: 0

MAP IPv6 address 2001:db8::1.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Mon, 28 Jan 2013 18:56:45 +0100

Senthil,

[...]

> section 2.2. So I think this figure is misleading.

perhaps we should just remove the RFC6052 reference then?
with a 48 bits of PSID + IPv4 address.
I don't mind if it is just IPv4 address, but then someone need to drive that discussion.

> |     n bits         |  o bits   | s bits  |   128-n-o-s bits      |

if we remove the 6052 reference, there is no u-octet.

> being consistent with RFC 6052 which allows one to configure a prefix of

just put the IPv4 address in the bottom bits, and allow it to be overwritten by the prefix.
it is just there for 'pretty printing' anyway.

cheers,
Ole

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Tue, 29 Jan 2013 02:49:59 +0000

>I don't mind if it is just IPv4 address, but then someone need to drive

I think the above figure should be clarified as an example when the
prefix-length+EA <= 64.
If the prefix length is greater than 64, the IPv4 address appears after
the prefix length and
U bits are overwritten.
If we clarify the above two points and remove the reference to rfc6052,
that would be fine.

Thanks
Senthil

---

From: [email-masked]
Date: Tue, 29 Jan 2013 14:54:30 +0800

Hi,Remi

[email-masked] 写于 2013-01-29 00:16:32:

> addresses, except those that start with the binary value 000, 
> Interface IDs are required to be 64 bits long and to be constructed 
> in Modified EUI-64 format". 
> 
> The draft says that:
> (a) The PSID is:
prefix."
> - And to the IPv4 address if the prefix is longer than /68? 

Remi, you mean the prefix is longer than /68 or /78?    I think /68(64+4) 
prefix doesn't overwrite IPv4 address.

BRs
Linda Wang

> - ...
> 
> Of course, if a use case is provided where MAP-E would be actually 
> used with an IID shorter than 64 bits, it should be discussed. But:
> >>>> and I don't see what it buys us, given that supporting prefix 
lengths
> >>>> longer than 64 is simple.
boundary.
> >> Tom, Remi and I have stated our opinions. does anyone else have a 
view on

---

From: [email-masked]
Date: Tue, 29 Jan 2013 15:03:13 +0800

Hi, Senthil,

> If the prefix length is greater than 64, the IPv4 address appears after

For example, prefix is /68, then IPv4 address appears at the 69-100 bits 
or there are still 4-bit for u bits,and IPv4 address appears at 73-104 
bits?

BRs
Linda Wang

> >>> Of course, if a use case is provided where MAP-E would be actually 
used

---

From: Rémi Després <[email-masked]>
Date: Tue, 29 Jan 2013 17:16:47 +0100

Hi, Linda,

2013-01-29 à 07:54, [email-masked] a écrit :

> > significant parts of the interface identifier is overwritten by the prefix."
> > 
> Remi, you mean the prefix is longer than /68 or /78?

Oops, I meant longer than 64 + 8, i.e. 72.
Thank you.

>    I think /68(64+4) prefix doesn't overwrite IPv4 address. 
> 
> BRs 
> Linda Wang 
> 
> 
> > - ...
> >

---

From: Rémi Després <[email-masked]>
Date: Wed, 30 Jan 2013 17:15:23 +0100

2013-01-28  17:36, Senthil Sivakumar (ssenthil) <[email-masked]>  :
...
> Honestly, I don¹t know the rationale behind this.

I wasn't present when this was written but can see that, at least, it made IIDs of LAN interfaces to be unique if based on MAC addresses that are assigned by LAN adapters by vendors in compliance with IEEE rules. 
This is AFAIK used by default in major OSes. 

> |     n bits         |  o bits   | s bits  |   128-n-o-s bits      |

Even simpler: don't repeat IPv4 addresses anywhere in IIDs.
- IPv4 are already available in encapsulated IPv4 headers, at fixed places
- With IPv4 addresses in IIDs, different treatments and interpretations are needed for CEs that are assigned IPv4 prefixes shorter than /32:
  . Zero padding up to 32 bits
  . No way in the IID itself to determine that the IPv4 address field contains a source or destination prefix as opposed to the source or destination IPv4 address.

Regards,
RD