Subject: 4rd IID range & IPv6 addressing architecture

From: Rémi Després <[email-masked]>
Date: Mon, 21 Jan 2013 17:19:49 +0100

Hi, Bob,

The discussion on whether the proposed 4rd IID range is "compatible with the IPv6 addressing architecture" has apparently come to a standstill.
Yet an answer of 6man to Softwire is expected.

A. To help making a WG decision, here are key points that, in my understanding, emerged from the discussion.

(a) Ray Hunter has provided a reference to RFC5342 which confirms that, in RFC 4291 compliant addresses, u=g=1 is "currently unused"   (www.ietf.org/mail-archive/web/ipv6/current/msg16890.html). 4rd addresses, which have u=g=1, therefore cannot conflict with current addresses of the IPv6 addressing architecture. (In particular, they don't conflict with those of RFC6740 ILNP.)

(b) Brian Carpenter pointed out that a 16-bit prefix would be sufficient for 4rd, taking less IID space than the currently proposed 8-bit prefix. This being acknowledged, the 0x0300 prefix can without problem replace the 0x03 prefix. (This doesn't change the 4rd specification which already has a 0x00 after 0x03.) With this prefix, the reserved range uses only 1/2^14 of the unused set of IIDs having u=g=1 is reserved. This leaves plenty of space for future uses of IIDs having u=1 (future uses explicitly envisaged in RFC 4291). 

(c) Jouni Korhonen pointed out that there is already an IANA registry for reserved IID ranges, and Simon Perreault gave the correct pointer to it (http://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xml).

(d) Suresh Krishnan pointed out that, according to RFC 5453, this registry is so far reserved for standard-track RFCs, the reason being "to minimize disruption to existing implementations". Although 4rd has been purposely designed so that it cannot disturb any existing implementation (precisely by using a currently unused IID range), the proposed 4rd range can be endorsed by IANA only if an RFC updates RFC 5453, explaining why a 4rd IID range can be safely assigned despite its experimental status. 
- If agreed on the principle, and if no one else volunteers, I can be available to propose a draft to this effect.

(e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of IIDs having u=g=1 is reserved. This leaves plenty of space for future uses of IIDs having u=1, as explicitly expected in RFC 4291. 
   
With this, 6man can IMHO answer that Softwire can proceed with 4rd, provided:
- the 16-bit IID prefix 0x0300 replaces the current 0x03
- it is understood that IANA won't register this IID range before a 6man RFC permits it for this experimental-track RFC.
 
No technically founded objection remains AFAIK, but if any one still holds it has of course to be expressed and discussed.

B. For those who are interested in a detailed summary of objections that were made, and have been answered, here is what I noted:

(i) If IETF uses u=g=1 in some unicast addresses, IEEE would have to be involved. 
- Because 4rd IIDs are never to be used in any MAC-layer addresses. IEEE isn't concerned.

(j) 4rd could work without a reserved range.
- As discussed in Softwire, reserving an IID range is key to satisfy the objective that "4rd IPv6 addresses are recognizable by CEs without any interference with the choice of subnet prefixes in CE sites".

(k) An IID range using the IANA OUI with u=1 and g=0 would have been sufficient.
- As discussed in Softwire, this wouldn't have left enough IID bits to contain the IPv4 address and the 16-bit CNP, which are both needed in 4rd.

(l) A 4rd-specific destination header could have been used instead of an IID-range.
-  An extra header would have defeated the 4rd objective that its "tunnel packets are valid IPv6 packets for all layer-4 protocols that use the same checksum algorithm as TCP".

(m) With a "reserved /64 on the customers delegated prefix for the sole use of 4rd",and 4rd nodes protecting "all possible 4rd interface-ids using DAD", a reserved range could have been avoided.
- This wouldn't work for IID assignments made before 4rd activation, while 4rd is designed to cover this case too. (Note also that 4rd implementations can add, on their LAN sides, exclusion of all addresses having the 4rd IID prefix. Although this isn't strictly needed, this can permit early detection of some erroneous manual configurations, and is easy to do due to the 4rd IID prefix being a constant.

(n) 4rd would fail if a customer link has two 4rd CEs.
- After discussion, no issue on this has been kept in Softwire.

Best regards,
RD

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 25 Jan 2013 08:58:04 +0000

Hi, Bob and 6man,

We do need an answer from 6man to move forward. So far, in my understanding, 6man has not answered the requirement/question raised by softwire chair.

Personally, I support the proposal to reserve a 4rd IID range (we can have max 16 fixed bit in order to reduce the reserved range). For this we need to update RFC 5453 to enable IID reservation for experimental RFCs. The value of reserved 4rd IID range can be discussed. The only requirement is the uniqueness.

Best regards,

Sheng

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of R
>émi Després
>Sent: Tuesday, January 22, 2013 12:20 AM
>To: Bob Hinden
>Cc: 6man 6man-wg
>Subject: 4rd IID range & IPv6 addressing architecture
>
>Hi, Bob,
>
>The discussion on whether the proposed 4rd IID range is "compatible with the
>IPv6 addressing architecture" has apparently come to a standstill.
>A. To help making a WG decision, here are key points that, in my
>understanding, emerged from the discussion.
>
>(a) Ray Hunter has provided a reference to RFC5342 which confirms that, in
>RFC 4291 compliant addresses, u=g=1 is "currently unused"
>(www.ietf.org/mail-archive/web/ipv6/current/msg16890.html). 4rd addresses,
>which have u=g=1, therefore cannot conflict with current addresses of the
>IPv6 addressing architecture. (In particular, they don't conflict with those of
>RFC6740 ILNP.)
>
>(b) Brian Carpenter pointed out that a 16-bit prefix would be sufficient for 4rd,
>taking less IID space than the currently proposed 8-bit prefix. This being
>acknowledged, the 0x0300 prefix can without problem replace the 0x03 prefix.
>(This doesn't change the 4rd specification which already has a 0x00 after
>0x03.) With this prefix, the reserved range uses only 1/2^14 of the unused set
>of IIDs having u=g=1 is reserved. This leaves plenty of space for future uses of
>IIDs having u=1 (future uses explicitly envisaged in RFC 4291).
>
>(c) Jouni Korhonen pointed out that there is already an IANA registry for
>reserved IID ranges, and Simon Perreault gave the correct pointer to it
>(http://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xml).
>
>(d) Suresh Krishnan pointed out that, according to RFC 5453, this registry is so
>far reserved for standard-track RFCs, the reason being "to minimize disruption
>to existing implementations". Although 4rd has been purposely designed so
>that it cannot disturb any existing implementation (precisely by using a
>currently unused IID range), the proposed 4rd range can be endorsed by IANA
>only if an RFC updates RFC 5453, explaining why a 4rd IID range can be safely
>assigned despite its experimental status.
>(e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of IIDs having
>u=g=1 is reserved. This leaves plenty of space for future uses of IIDs having
>u=1, as explicitly expected in RFC 4291.
>
>- it is understood that IANA won't register this IID range before a 6man RFC
>permits it for this experimental-track RFC.
>
>No technically founded objection remains AFAIK, but if any one still holds it
>has of course to be expressed and discussed.
>
>
>
>B. For those who are interested in a detailed summary of objections that were
>made, and have been answered, here is what I noted:
>
>- As discussed in Softwire, reserving an IID range is key to satisfy the objective
>that "4rd IPv6 addresses are recognizable by CEs without any interference
>with the choice of subnet prefixes in CE sites".
>
>- As discussed in Softwire, this wouldn't have left enough IID bits to contain
>the IPv4 address and the 16-bit CNP, which are both needed in 4rd.
>
>-  An extra header would have defeated the 4rd objective that its "tunnel
>packets are valid IPv6 packets for all layer-4 protocols that use the same
>checksum algorithm as TCP".
>
>(m) With a "reserved /64 on the customers delegated prefix for the sole use
>of 4rd",and 4rd nodes protecting "all possible 4rd interface-ids using DAD", a
>reserved range could have been avoided.
>- This wouldn't work for IID assignments made before 4rd activation, while
>4rd is designed to cover this case too. (Note also that 4rd implementations
>can add, on their LAN sides, exclusion of all addresses having the 4rd IID
>prefix. Although this isn't strictly needed, this can permit early detection of
>some erroneous manual configurations, and is easy to do due to the 4rd IID
>prefix being a constant.
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 28 Jan 2013 15:06:02 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Rémi Després
> Sent: Monday, January 21, 2013 8:20 AM
> To: Bob Hinden
> Cc: 6man 6man-wg
> The discussion on whether the proposed 4rd IID range is "compatible with
> the IPv6 addressing architecture" has apparently come to a standstill.
> (a) Ray Hunter has provided a reference to RFC5342 which confirms that,
> in RFC 4291 compliant addresses, u=g=1 is "currently unused"
> (www.ietf.org/mail-archive/web/ipv6/current/msg16890.html). 4rd
> addresses, which have u=g=1, therefore cannot conflict with current
> addresses of the IPv6 addressing architecture. (In particular, they
> don't conflict with those of RFC6740 ILNP.)
> 
> (b) Brian Carpenter pointed out that a 16-bit prefix would be sufficient
> for 4rd, taking less IID space than the currently proposed 8-bit prefix.
> This being acknowledged, the 0x0300 prefix can without problem replace
> the 0x03 prefix. (This doesn't change the 4rd specification which
> already has a 0x00 after 0x03.) With this prefix, the reserved range
> uses only 1/2^14 of the unused set of IIDs having u=g=1 is reserved.
> This leaves plenty of space for future uses of IIDs having u=1 (future
> uses explicitly envisaged in RFC 4291).
> 
> (c) Jouni Korhonen pointed out that there is already an IANA registry
> for reserved IID ranges, and Simon Perreault gave the correct pointer to
> it (http://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-
> ids.xml).
> 
> (d) Suresh Krishnan pointed out that, according to RFC 5453, this
> registry is so far reserved for standard-track RFCs, the reason being
> "to minimize disruption to existing implementations". Although 4rd has
> been purposely designed so that it cannot disturb any existing
> implementation (precisely by using a currently unused IID range), the
> proposed 4rd range can be endorsed by IANA only if an RFC updates RFC
> 5453, explaining why a 4rd IID range can be safely assigned despite its
> experimental status.
> - If agreed on the principle, and if no one else volunteers, I can be
> available to propose a draft to this effect.

Seems reasonable.

> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
> IIDs having u=g=1 is reserved. This leaves plenty of space for future
> uses of IIDs having u=1, as explicitly expected in RFC 4291.

That goes to the argument of (d), that it isn't harmful to assign
some space to 4rd.

-d

> - it is understood that IANA won't register this IID range before a 6man
> RFC permits it for this experimental-track RFC.
> 
> No technically founded objection remains AFAIK, but if any one still
> holds it has of course to be expressed and discussed.
> 
> 
> 
> B. For those who are interested in a detailed summary of objections that
> were made, and have been answered, here is what I noted:
> 
> - As discussed in Softwire, reserving an IID range is key to satisfy the
> objective that "4rd IPv6 addresses are recognizable by CEs without any
> interference with the choice of subnet prefixes in CE sites".
> 
> - As discussed in Softwire, this wouldn't have left enough IID bits to
> contain the IPv4 address and the 16-bit CNP, which are both needed in
> 4rd.
> 
> -  An extra header would have defeated the 4rd objective that its
> "tunnel packets are valid IPv6 packets for all layer-4 protocols that
> use the same checksum algorithm as TCP".
> 
> (m) With a "reserved /64 on the customers delegated prefix for the sole
> use of 4rd",and 4rd nodes protecting "all possible 4rd interface-ids
> using DAD", a reserved range could have been avoided.
> - This wouldn't work for IID assignments made before 4rd activation,
> while 4rd is designed to cover this case too. (Note also that 4rd
> implementations can add, on their LAN sides, exclusion of all addresses
> having the 4rd IID prefix. Although this isn't strictly needed, this can
> permit early detection of some erroneous manual configurations, and is
> easy to do due to the 4rd IID prefix being a constant.
>

---

From: Ole Troan <[email-masked]>
Date: Tue, 29 Jan 2013 14:18:08 +0100

[...]

> That goes to the argument of (d), that it isn't harmful to assign

I still think we need to answer the question Brian raised.
should the interface-id have any encoded meaning?

cheers,
Ole

---

From: Sander Steffann <[email-masked]>
Date: Tue, 29 Jan 2013 14:29:43 +0000

Hi,

> should the interface-id have any encoded meaning?

I don't see any benefit of certain bits in the interface-id having special meanings, but that might be because of a lack of vision on my side :-)

- Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Jan 2013 14:32:07 +0000

> should the interface-id have any encoded meaning?

That will not be done overnight. I've been thinking about it and
have some ideas about how to write a discussion draft, but it is
unfortuante to make the 4rd work queue behind us. Is there any risk
in doing as Rémi suggested?

On 21/01/2013 16:19, Rémi Després wrote:
...
> - it is understood that IANA won't register this IID range before a 6man RFC permits it for this experimental-track RFC.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Tue, 29 Jan 2013 18:28:23 +0100

Brian,

> in doing as Rémi suggested?

it depends on what the expected meaning of a reservation is.
should all implementations treat the reserved part of the interface-id as martian,
and prohibit a user from configuring it for another purpose than 4rd?

or is it just a 'suggestion' for interface-id's that the 4rd mechanism can use, and the operator
deploying it will make sure there are no conflicts?

one of my concerns is that continuing to add the interface-id bits, is the opposite direction of where
I want us to go.

I wouldn't object to non-normative language in 4rd suggesting a interface-id to use, without
creating any expectation that new or existing IPv6 implementations have to change.

that said, 4rd will work perfectly well _without_ this reservation, so I don't buy the argument that
we're holding up the 4rd work.

cheers,
Ole

---

From: Randy Bush <[email-masked]>
Date: Wed, 30 Jan 2013 09:14:54 +0900

> should the interface-id have any encoded meaning?

having spent a decade+ fighting to throw magic bits out of ipv6
addressing (remember tla?), i find this disturbing.

randy

---

From: Fernando Gont <[email-masked]>
Date: Tue, 29 Jan 2013 22:17:52 -0300

> should the interface-id have any encoded meaning?

The only point having an encoding meaning is that, *in theory*, if you
have a Universal/Local bit, and you have a source of universal
identifiers, then you could tell beforehand that you're not going to
have address collisions. However,

* Practice indicates that "universal" identifiers are reused
(virtualization software being just one example). And when you find a
collision, you still need some other scheme to generate the IIDs (or
else, how are you going to solve the DAD failure).

* You'd need some coordination to separate the different namespaces
(that's why we stuff the fffe for IEEE Identifiers, right?)

* We must implement slaac anyway, so.. who cares about the
aforementioned uniqueness?

* Those universal identifiers bring patters, which are undesirable (see
e.g. draft-ietf-opsec-ipv6-host-scanning).

For the stable addresses, what we should be doing is replace the
IEEE-derived scheme with draft-ietf-6man-stable-privacy-addresses, and
be done with it. (probably eminating that of clearing the U bit in the
IID, though).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Rémi Després <[email-masked]>
Date: Wed, 30 Jan 2013 14:20:46 +0100

2013-01-29  18:28, Ole Troan <[email-masked]>  :

...
> should all implementations treat the reserved part of the interface-id as martian,

No.

> and prohibit a user from configuring it for another purpose than 4rd?

Already done since, today, no RFC4291 unicast address may have u=g=1 (a point confirmed during the discussion). 

> one of my concerns is that continuing to add the interface-id bits, is the opposite direction of where

Unless you want to modify RFC4291 without backward compatibility, I don't see why using an unused IID range having u=1 could be harmful. 
("The use of the universal/local bit in the Modified EUI-64 format identifier is to allow development of future technology that can take advantage of interface identifiers with universal scope").

> creating any expectation that new or existing IPv6 implementations have to change.

On this, we agree: the fact that 4rd needs no change of existing IPv6 implementations that don't support is key.

The RFC that is needed to reserve a 4rd IID-range despite its being experimental is, in my understanding, the natural place to make this clear.

> we're holding up the 4rd work.

As explained in various ways several times, reserving a currently unused IID range ensure that, when 4rd is activated in customer site, no renumbering of any RFC-compliant link or host is necessary. Without that, 4rd wouldn't be up to its objectives.

regards,
RD

---

From: Ole Troan <[email-masked]>
Date: Wed, 30 Jan 2013 14:34:44 +0100

Remi,

> Already done since, today, no RFC4291 unicast address may have u=g=1 (a point confirmed during the discussion). 

apologies for being a little flippant.
but that point isn't confirmed.

actually I'm using that space:

otroan@ubuntu:~/src/as$ ifconfig lo
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: 2001:db8::ffff:0:0:1/64 Scope:Global
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:354 errors:0 dropped:0 overruns:0 frame:0
          TX packets:354 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:44161 (44.1 KB)  TX bytes:44161 (44.1 KB)

otroan@ubuntu:~/src/as$ sudo ip addr add 2001:db8:0000:0000:FFFF::1/64 dev lo

> ("The use of the universal/local bit in the Modified EUI-64 format identifier is to allow development of future technology that can take advantage of interface identifiers with universal scope").

yes, that technology is called ILNP. it does not require globally unique interface identifiers.
which in any case would have required some sort of registry.

> The RFC that is needed to reserve a 4rd IID-range despite its being experimental is, in my understanding, the natural place to make this clear.

my argument is that you don't need a reservation.

> As explained in various ways several times, reserving a currently unused IID range ensure that, when 4rd is activated in customer site, no renumbering of any RFC-compliant link or host is necessary…

if we agree that the interface-id is just 64bits of nothingness, then there is no such thing as an unused IID space.
pick whatever you like for the 4rd IID, but your protocol needs to deal with collisions.

cheers,
Ole

---

From: Sander Steffann <[email-masked]>
Date: Wed, 30 Jan 2013 14:13:01 +0000

Hi,

> pick whatever you like for the 4rd IID, but your protocol needs to deal with collisions.

Dealing with collisions is very probably necessary anyway (virtual machine cloning was already mentioned as a potential cause of conflicts). I think this is the right approach.

- Sander

---

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

> apologies for being a little flippant.

Your apologies are welcome (see below).

> otroan@ubuntu:~/src/as$ sudo ip addr add 2001:db8:0000:0000:FFFF::1/64 dev lo

Independently of the above details, address 2001:db8::ffff:0:0:1 isn't an RFC4269-compliant address! (My sentence was only about RFC4269 addresses.) 

Incidentally:
- Note that the particular IID of this address has no conflict with the proposed 4rd IID range. It can coexist without any risk.
- Why don't you ask for reserving this IID for your particular application? This would eliminate the risk of someone else taking the same for another manual configuration (i.e. one that DAD doesn't  repair).

> which in any case would have required some sort of registry.

ILNP, which has u=0.
Out of scope!

> if we agree that the interface-id is just 64bits of nothingness, then there is no such thing as an unused IID space.

We don't agree that what is in RFC 4291 should be ignored.
 
> pick whatever you like for the 4rd IID, but your protocol needs to deal with collisions.

Not AFAIK, but since 4rd is intended to be experimental, this will be verified anyway.

If you have identified a detailed configuration which would suffer from collisions, I hope you will submit it to Softwire for the 6 4rd-draft authors to look at it.

Let me wonder when you will stop introducing in 6man new arguments against 4rd operation.

RD

---

From: Ray Hunter <[email-masked]>
Date: Wed, 30 Jan 2013 16:59:01 +0100

inline.

Ole Troan wrote:
>>>>> IIDs having u=1 is reserved. This leaves plenty of space for future
>>>>> uses of IIDs having u= as explicitly expected in RFC 4291.
my 2 cents.

If 4rd is truly experimental then indeed I think it's up to the
operators deploying it to ensure they choose a unique IID range within
the scope of where they are operating 4rd (between tunnel endpoints and
the tunnel gateway). My initial concerns were that this could cause harm
even in experimental form, but I've convinced myself that it shouldn't.
In this case I see no need for a hard global IID reservation, because at
the moment, u=1 g=1 isn't used for creating IID's for use with SLAAC.

On the other hand, If 4rd is not truly experimental, or it's expected to
work universally across AS boundaries, I suspect the WG will have to
wait for an answer to Brian's question on whether structure within the
IID is desirable. I don't think there's any clear consensus so far on
that point (indeed there are some counter posts saying structure within
the IID is undesirable).

My own particular concern here is that there is a danger of creating a
precedent of a completely new class of IPv6 addressing by the back door
without this being fully and properly debated i.e. address ranges that
don't perform DAD, and that are associated directly with a certain
tunnel or transport protocol, and yet which are assigned within the
generic GUA space, but perhaps which overlap with other IPv6 prefix
spaces too.

e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used by
6to4 (2002::/16) being associated with 4rd IIDs?

e.g. 2 How would this new class of IID encoded ranges/tunnel/transport
protocols interact with RFC6724 and draft-ietf-6man-addr-select-opt-08
(both of which assume that bit-contiguous left-anchored IPv6 prefixes
map to transport protocols, not individual IID bits)?

These questions probably have little relevance to 4rd being deployed in
an experimental situation, and I think we should perhaps try to keep
them decoupled as far as possible.

---

From: GangChen <[email-masked]>
Date: Thu, 31 Jan 2013 15:53:37 +0800

> the moment, u=1 g=1 isn't used for creating IID's for use with SLAAC.

Just some comments from operational views. I guess it's true operators
could avoid confliction with u=1 g=1 in near future. However, I
believe that is relative short-term guarantee with the condition of a
particular operational domain. The term of "experimental" is not
really mean "experimental" to a commercial network. It would be safe
for operations if there is legitimate registry to ensure there is no
need to renumbering. Therefore I prefer Remi's proposal (e) to grant
4rd 0x0300.

Best Regards

Gang

---

From: Ray Hunter <[email-masked]>
Date: Thu, 31 Jan 2013 11:26:59 +0100

> GangChen <mailto:[email-masked]>
> 31 January 2013 08:53

I disagree.

See http://www.ietf.org/iesg/informational-vs-experimental.html

IMVHO "Experimental" means everything could change: including a need for
mass renumbering or equipment replacement.

Publication is "Subject only to editorial considerations and to
verification that there has been adequate coordination with the
standards process." No guarantees. The test I am currently applying when
reviewing this ID is whether the experiment is likely to cause harm.

I see no compelling reason at this time to define a global reservation
or an explicit IID structure in order for the experiment to be able to
proceed and succeed. On the other hand, adding a reservation and
structure to the IID at this time would likely impact other
implementations (e.g. packet classifiers) and existing documents and IDs
(e.g. address selection).

If you want 4rd to be "informational" or "standards track" I also think
that's worth discussing, but then I also think there's a lot more to
specify and discuss beyond the current ID.

> Ray Hunter <mailto:[email-masked]>
> 30 January 2013 16:59
> inline.
>
> Ole Troan wrote:
>> Brian,
>>
> ------------------------------------------------------------------------

---

From: Rémi Després <[email-masked]>
Date: Thu, 31 Jan 2013 11:38:54 +0100

2013-01-30  16:59, Ray Hunter <[email-masked]>  :
...
> the tunnel gateway).

This misses the point that 4rd IIDs are chosen to be collision-free with all possible IPv6 hosts that, in sites that use 4rd for IPv4, are configured with SLAAC (and therefore have to comply with RFC4291). 
IIDs of these hosts are assigned independently of any knowledge that 4rd is used or not.

> My initial concerns were that this could cause harm
> that point

> (indeed there are some counter posts saying structure within
> the IID is undesirable).

OK, it is a fact that, *for some addresses that aren't concerned with SLAAC*, typically some manually configured addresses, the IID structure of RFC 4291 can be ignored. One example where it is actually ignored is in RFC 6164  which deals with /127 prefixes on inter-router links. (Incidentally, I have been an active supporter of this RFC, as Miya Kohno may remember.

But it is ALSO A FACT that *for IIDs that are used in SLAAC* there is some IID structure, the so called Modified EUI-64 format. (If u=0, other bits have no structure; if u=1, other bits must be based on IEEE link addresses. They then always have g=0, other combinations remaining available for future technologies.)
This structure is effectively used in OSes to automatically provide, by default, addresses that are stable in their environment. If MUST NOT be abandoned for addresses subject to SLAAC.

> 6to4 (2002::/16) being associated with 4rd IIDs?

6to4 IIDs are ordinary unicast-address IIDs, subject to RFC 4291. 
Consistency of the 4rd IID range with RFC 4291 therefore avoids any risk of conflict with 6to4. 

> map to transport protocols, not individual IID bits)?

4rd addresses are those of tunnel endpoints in BRs and CEs. They are therefore not concerned with Address selection policies that are needed for applications having to choose among several source and/or destinations.

> them decoupled as far as possible.

Reservation of an unused IID range among those of RFC4291 is in my understanding already decoupled from the above issues. This reservation would be as safe if 4rd would be on standard track instead of experimental.

Regards,
RD

---

From: Ole Troan <[email-masked]>
Date: Thu, 31 Jan 2013 11:42:27 +0100

agree with what Ray says. that gives a path forward for 4rd without requiring us to settle the interface-id structure question.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Thu, 31 Jan 2013 12:08:19 +0100

...
> (e.g. address selection).

Please see the answer on this point in my previous email to you.

> that's worth discussing,

"Experimental" or "standard" has been abundantly discussed in Softwire. "Experimental" is THE CONCLUSION, worth leaving as is. 

The question to 6man is whether 6man confirms, or not, that the proposed IID-range reservation is compatible with the IPv6 addressing architecture (as found after a thorough study of the subject before proposing it).

> but then I also think there's a lot more to

Being more specific would clarify what you mean by this "lot more" 
It should preferably be in Softwire if it doesn't concern 6man, or even be in a private discussion if you didn't follow previous work on the subject. 
I will do my best to answer.

Regards,
RD

---

From: Ray Hunter <[email-masked]>
Date: Thu, 31 Jan 2013 12:32:15 +0100

> IIDs of these hosts are assigned independently of any knowledge that 4rd is used or not.
Understood. No new reservation is required. No new behaviour is required
of existing hosts.
>> the moment, u=g=1 isn't used for creating IID's for use with SLAAC.
>>
Understood.  People running 4rd have to ensure manually assigned
addresses avoid the 4rd range.
Making a global reservation or not will likely not significantly change
the impact of that.
> But it is ALSO A FACT that *for IIDs that are used in SLAAC* there is some IID structure, the so called Modified EUI-64 format. (If u= other bits have no structure; if u=1, other bits must be based on IEEE link addresses. They then always have g=0, other combinations remaining available for future technologies.)
Understood. No new reservation is required. No new behaviour is required
of existing hosts. 
> Consistency of the 4rd IID range with RFC 4291 therefore avoids any risk of conflict with 6to4. 
Right, so you're saying it's perfectly valid to combine a 64 bit 6to4
prefix with a 64 bit 4rd IID?

Won't anything that currently assumes 6to4 has exclusive use of
2002::/16 potentially have a problem, because actually the traffic isn't
really 6to4?
> 4rd addresses are those of tunnel endpoints in BRs and CEs. They are therefore not concerned with Address selection policies that are needed for applications having to choose among several source a…
So a CE router never sources or terminates an IPv4 or IPv6 session?

So a 4rd tunnel will never terminate on an end user device?

What about mobile phones and tablets attached to IPv6 only networks?
Wouldn't it be very attractive (and therefore likely) for them to act as
their own 4rd tunnel endpoint?

---

From: Rémi Després <[email-masked]>
Date: Thu, 31 Jan 2013 15:17:24 +0100

Ray,

Thanks for the acknowledgements of point that are now understood.
More clarification inline on others.

> 2002::/16 potentially have a problem, because actually the traffic isn't

6to4 is only a way to assign IPv6 PREFIXES.
IID constraints of RFC 4291 do apply to its IIDs, like with any other IPv6 prefix.
Nothing new concerning 6to4 in particular is therefore introduced by 4rd.

> their own 4rd tunnel endpoint?

Very attractive indeed, and definitely a target (for 4rd as for MAP-E).

All incoming traffic having the 4rd destination address goes to the IPv6 interface of the CE function. It is then forwarded, in IPv4, to its IPv4 virtual interface. 
Conversely, the CE function is the only one that may sends packets with the the 4rd IPv6 address as source. 
Ref. http://www.ietf.org/proceedings/85/slides/slides-85-softwire-5.ppt

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 31 Jan 2013 15:44:05 +0100

> agree with what Ray says. that gives a path forward for 4rd without requiring us to settle the interface-id structure question.

Do you mean by this that "4rd will work perfectly well _without_ this reservation"?

- If not, please clarify what you mean.

- If yes, you forgot (once more!) that this reservation is what eliminates the risk of collisions with host addresses that, in 4rd sites, comply with RFC 4291.  
In my understanding, Ray has now acknowledged this point.

RD

---

From: Ray Hunter <[email-masked]>
Date: Thu, 31 Jan 2013 16:35:23 +0100

> Rémi Després <mailto:[email-masked]>
> 31 January 2013 15:44
No.

I acknowledge that I understood that no new behaviour is required of
existing implementations, and no existing standards need updating for
successful experimental deployment of 4rd.

I do not acknowledge that a (new) global IID reservation is necessary at
this time for 4rd to function perfectly correctly in an experimental
deployment.

In practical terms, a (new) reservation for experimental deployment of
4rd makes no difference whatsoever.

If there are few or no collisions at the IID level (as we expect), then
there's no need for a reservation for experimental 4rd at this time.

If there are collisions (e.g. due to static numbering) they'll have to
be renumbered or reconfigured before 4rd is deployed in that environment
whether a new reservation has been made in an RFC or not. Publishing an
RFC and registering something in IANA won't change the facts on the ground.

So unless you plan to update existing standards and/or require a
universal update of all non-4rd-aware implementations and deployments
(which I feel would be well beyond the spirit of the experimental status
of 4rd) I see no significant value in the assignment at this time.

And I don't see 6man assigning these u=1 g=1 EUI64 derived IID bits for
any other use at the moment either. But if the WG did decide to do that,
that would IMHO be the time to make the reservation, and to include a
range for exclusive use by 4rd if it was ever likely to move to
standards track.

regards,

> Ole Troan <mailto:[email-masked]>
> 31 January 2013 11:42
> agree with what Ray says. that gives a path forward for 4rd without
> requiring us to settle the interface-id structure question.
>
> cheers,
> Ole
>
>
>
> 31 January 2013 11:26

---

From: Roger Jørgensen <[email-masked]>
Date: Thu, 31 Jan 2013 17:25:44 +0000

> agree with what Ray says. that gives a path forward for 4rd without requiring us to settle the interface-id structure question.

For what it's worth, I also agree with Ray.

Nothing brought forward by or from 4rd have convince me about anything else.

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Rémi Després <[email-masked]>
Date: Thu, 31 Jan 2013 18:28:40 +0100

2013-01-31 16:35, Ray Hunter <[email-masked]>:

>> - If yes, you forgot (once more!) that this reservation is what eliminates the risk of
>> collisions with host addresses that, in 4rd sites, comply with RFC 4291.

> No.

I see. Thanks for the clarification. 
> Understood. No new reservation is required. No new behaviour is required
(At least you didn't negate that the proposed 4rd range reservation eliminates the risk of collisions with hosts that, in 4rd sites, use SLAAC.) 

> successful experimental deployment of 4rd.

OK. This remains important.

> this time for 4rd to function perfectly correctly in an experimental

The difference you make between working "perfectly" "in an experimental environment" and working "perfectly" in some other environment, say in production environment, is unclear to me. 

The 4rd specification has been frozen for a long time now. It is only waiting for the 6man response on compatibility of its reserved IID range with the IPv6 addressing architecture. 

The decision to keep 4rd experimental has been made to avoid several similar standards, but not because of remaining issues on its ability to work in production environments. 

> 4rd makes no difference whatsoever.

Well, this reservation does ensure that no other reservation can be made, at any time, which would conflict with that used for 4rd.
The registry of reserved IID ranges is precisely the place to ensure it.

> there's no need for a reservation for experimental 4rd at this time.

Completed designs, if available and simple, are better than designs that are already known to be incomplete *including for experiments*. 

In this instance, no possible collisions is better than possibly a few (with additional precautions to deal with them, and risks of having to renumber). 

Is it right to suppose we can agree on this?

> of 4rd) I see no significant value in the assignment at this time.

Requiring a "universal update of all non-4rd-aware implementations and deployments" wouldn't make sense at all!
If you think 4rd might introduce such a requirement, could you please explain?

The only standard-track update that is needed concerns RFC 5453, to permit an IID-range reservation for an experimental track solution that doesn't imply any "disruption to existing implementations".  

> any other use at the moment either.

I don't see any either... but sometimes progress needs a pioneer case ;-).

> But if the WG did decide to do that,

If 4rd may ever be moved to standard track despite its level of commonality with MAP-E, it would only be because its functional differences are then found significant enough. In view of the recent debate in Softwire, its happening in any short term is very doubtful. 

Yet, what will happen in the longer term belongs to the future.
Today, let's just do things right. 
In this instance, this means reserving the IID range that is needed for 4rd to be up to its objectives.

Regards,
RD

---

From: GangChen <[email-masked]>
Date: Fri, 1 Feb 2013 11:57:41 +0800

Hello Ray,

2013/1/31, Ray Hunter <[email-masked]>:
>>>> should all implementations treat the reserved part of the interface-id
>>>> as
>>>> martian,
>>>> or is it just a 'suggestion' for interface-id's that the 4rd mechanism
>>>> can
>>>> use, and the operator

Understood your objection.

If "Experimental" was claimed to not be "No guarantees" due to
"Subject only to editorial considerations and to verification that
there has been adequate coordination with the standards process."

I would say 4rd seems a different story.

It was proposed as "standard track".  The label of "experimental" was
made because Softwire group needs to determine the way moving on among
competing solutions, not technical limitation to a commerical network.

It's regretful to not allow 4rd with the ability since the
"experimental" is underqualified to reservation.

> proceed and succeed.

May I understand the "no compelling reason" means V bits
recommendation fits into "Experimental" status?

> On the other hand, adding a reservation and

I have a different view. If there is no prompt reservation, it may
likely have such impact.

Best Regards

Gang

>>>> one of my concerns is that continuing to add the interface-id bits, is
>>>> the
>>>> opposite direction of where
>>>> I want us to go.
>>>>
>>>> creating any expectation that new or existing IPv6 implementations have
>>>> to
>>>> change.
>>>>
>>>> that said, 4rd will work perfectly well _without_ this reservation, so
>>>> I
>>>> don't buy the argument that