Subject: Relaxing two unnecessary constraints on IID fields

From: Rémi Després <[email-masked]>
Date: Mon, 27 Jul 2009 22:27:30 +0200

Two constraints on IPv6 address formats appear to be unnecessary  
while prohibiting some designs that are useful to enhance IPv6 benefits:

- One concerns addresses that never appear on any IPv6 link.
Since only purpose of these addresses is to derive from them some  
local addresses subject to IID constraints, they shouldn't, be  
themselves, be required to include 64-bit IID fields with their  
restricted format (u and g bits specified values).

- The second one concerns a strict interpretation of RFC 4291 that  
permits new IID formats ONLY for global-scope IIDs.
It happens that some new IID formats with local scope could also be  
useful.

The recent draft on Multihoming across local-addressing routing zones  
proposes a design that requires these two unnecessary constraints to  
be relaxed (ref tools.ietf.org/html/draft-despres-sam-03).
Its section 2.5 and its note in section 3.2.2 introduce the subject.

The 6man agenda was already too heavy for a presentation during this  
meeting, but the subject is clearly in the scope of the WG.
It is introduced for further consideration.

Regards,
RD

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 29 Jul 2009 10:06:12 -0400

Hi Remi,

> restricted format (u and g bits specified values).

As I understand it, you are not (in the my terminology) talking about  
addresses that will not appear on any IPv6 link...  You are talking  
about addresses, such as the global addresses in your SAM proposal,  
that will be used as the source and destination addresses of routed IP  
packets.  Right?

You are suggesting that there may be ways to improve IPv6 that would  
require modification to the current IPv6 unicast address format, so  
that routing prefixes can be longer than 64-bits and IIDs can be  
shorter than 64 bits.  Right?

I am still not 100% sure where/when you are talking about using these  
longer prefixes...

They would be used in IP packet headers that are routed across the  
network.  Would they also be used in RAs?  Would they be assigned via  
DHCP?  Would hosts be expected to generate privacy addresses in these  
prefixes?

Longer prefixes are supported in most of the IPv6 RFCs, but there are  
some exceptions.  There also may be restrictions in applications, such  
as routers that are optimized to route on the first 64 bits of the  
address, tools that won't let you enter more than a 64-bit prefix,  
etc.  So, personally, I think we would need a very compelling reason  
to allow longer prefixes.

> It happens that some new IID formats with local scope could also be  

If I understand this request correctly, you are asking whether it  
would be okay to use IIDs with the "u" bit set (indicating that they  
are globally unique IIDs) that are _not_ based on a modified EUI-64  
identifier.  Is that correct?

This would undo some of the changes we made (as a results of the GSE/ 
8+8 discussions) to allow for nodes to have globally-unique IIDs.  It  
is not clear to me that we've realized any possible benefit from those  
unique global IIDs, but we should understand what we are giving up  
before we do so.

Margaret

---

From: Rémi Després <[email-masked]>
Date: Wed, 29 Jul 2009 17:46:25 +0200

Margaret,

Thanks for your questions and comments.

Answers below.

RD

Le 29 juil. 09 à 16:06, Margaret Wasserman a écrit :

> As I understand it, you are not (in the my terminology) talking  
> about addresses that will not appear on any IPv6 link...  You are  
> talking about addresses, such as the global addresses in your SAM  
> proposal, that will be used as the source and destination addresses  
> of routed IP packets.  Right?

You are right.
(What I wrote is therefore not completely accurate, and has to be  
changed.)

The SAM addresses with a series of infixes (local IDs) that exceeds  
64 bits  may indeed appear on links of the Internet outside of SAM  
clouds (routing zones).
On these, they are forwarded to MAC addresses that are those of next  
hop routers.
They therefore don't participate in the neighbor discovery protocol  
of links where they appear.

> You are suggesting that there may be ways to improve IPv6 that  
> would require modification to the current IPv6 unicast address  
> format, so that routing prefixes can be longer than 64-bits and  
> IIDs can be shorter than 64 bits.  Right?

Only if these addresses never participate in a neighbor discovery  
protocol.

> I am still not 100% sure where/when you are talking about using  
> these longer prefixes...

SAM infixes in general, and those that appear beyond the 64 first  
bits like any others, are only processed in ingress and egress nodes  
of SAM clouds. In ingress nodes, they are used to derive local  
addresses; in egress nodes, they are used to check consistency of  
local addresses with infixes contained in global addresses.
> network.  Would they also be used in RAs?
No.

> Would they be assigned via DHCP?
No.

>   Would hosts be expected to generate privacy addresses in these  
> prefixes?
No.

> Longer prefixes are supported in most of the IPv6 RFCs, but there  
> are some exceptions.  There also may be restrictions in  
> applications, such as routers that are optimized to route on the  
> first 64 bits of the address, tools that won't let you enter more  
> than a 64-bit prefix, etc.
There is no case where a SAM global address would need to be routed  
on more than 64 bits.

>   So, personally, I think we would need a very compelling reason to  
> allow longer prefixes.

Permitting to extend a prefix hierarchy in a customer site where  
several prefixes are received, as easily with a /56 or even /64 as  
with a /48 is IMHO important.

I would rather ask for a compelling reason to prevent it from happening.
>> It happens that some new IID formats with local scope could also  
>> be useful.
>
>
> would be okay to use IIDs with the "u" bit set (indicating that  
> they are globally unique IIDs) that are _not_ based on a modified  
> EUI-64 identifier.  Is that correct?
>
> This would undo some of the changes we made (as a results of the  
> GSE/8+8 discussions) to allow for nodes to have globally-unique  
> IIDs.  It is not clear to me that we've realized any possible  
> benefit from those unique global IIDs, but we should understand  
> what we are giving up before we do so.
>
> Margaret
>
>
>

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 29 Jul 2009 09:47:50 -0400

Hi Remi,

Margaret