Subject: Re: Mail from softwire working group about 4rd

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Dec 2012 10:55:05 +0000

Hi Suresh,

> The 4rd draft (http://tools.ietf.org/html/draft-ietf-softwire-4rd-04)
> describes a solution for providing IPv4 connectivity over IPv6. The
> draft describes the method for mapping 4rd IPv4 addresses to 4rd IPv6
> Addresses. It uses a 4rd specific mark called the V octet in the first 8
> bits of the Interface Identifier. There were some concerns raised in
> softwire about whether such addresses are actually compatible with the
> IPv6 addressing architecture. Whether this is actually compatible with
> the IPv6 addressing architecture is outside the scope of the softwire
> wg. Hence we would like to hear the 6man wg's perspective on this. I
> would like to request the wg to please go over the NOTE in Section 4.5
> page 18, which explains the issue, and over IANA Considerations Section
> 6, and chime in on whether this is acceptable from a 6man perspective.

It certainly makes me nervous. The proposed format misuses the "g" bit,
which is supposed to flag multicast. Can it be proved beyond doubt that
such an address will never escape a context in which the V octet will
only be interpreted 4rd-style? This is not clear to me from the draft.

I would be less nervous if you could also set the OUI bits to a reserved
value for this purpose.

          For this, the V octet has its "u" and "g" bits of
          [RFC4291] both set to 1, so that they differ from "u" =
          0, reserved for Interface IDs that have local-scope, and
          also differs from "u" = 1 and "g"= 0, reserved for
          unicast Interface IDs using the EUI-64 format.  Bits

That should be "modified EUI-64 format"

          other than "u" and "g", are proposed to be 0, giving V =
          0x03. 4rd is thus the first "future technology that can
          take advantage of interface identifiers with universal
          scope" [RFC4291].

I find that sentence hard to swallow. It's recycling the u and g bits
but I don't see how it takes advantage of universal scope. I would
just delete the sentence.

          As such, it needs to be endorsed by
          the 6man working group and IANA (Section 6).

This sentence too can be deleted before RFC publication.

   o  An IPv6 Interface-ID type reserved for 4rd (the V octet of
      Section 4.5).  For this creation of new registry is suggested for
      Interface-ID types of unicast addresses that have neither local
      scope nor the universal scope of Modified EUI-64 format
      [RFC4291]).  This registry is intended to be used for new
      Interface-ID types that may be useful in the future.

I don't get this. The possible ug combinations are all theoretically
valid today, aren't they? 11 means globally unique multicast. The only
way you can protect them as a 4rd flag is by using a dummy OUI value,
as far as I can see. I think that is what you should ask for (from
IEEE, not IANA).

Regards
   Brian Carpenter

---

From: Rémi Després <[email-masked]>
Date: Tue, 11 Dec 2012 15:35:58 +0100

Hi Brian,

Thank you for the quick comments on this issue.
Let me explain more below.

2012-12-11 11:55, Brian E Carpenter <[email-masked]>:

> which is supposed to flag multicast.

> Can it be proved beyond doubt that
> only be interpreted 4rd-style?

No, but this is AFAIK acceptable:
- If a 4rd packet enters, in a 4rd domain, a customer site that has no 4rd CE will be routed in this site like any other IPv6 packet, based on its IPv6 prefix.
- It is guaranteed, however, that no properly configured interface will ever be reached at this address. Reason is precisely that no properly configured host may have an interface ID starting with the 4rd exclusive /8 prefix.

This prefix is so far called the V octet, for historical reasons, but could IMHO be advantageously renamed to be more intuitive (e.g. 4rd IID prefix).
 
> This is not clear to me from the draft.
> 

Unfortunately, it proved to be impossible: this wouldn't have left 48 bits for the IPv4 address and the 16-bit checksum-neutrality preserver. Both have to fit in the IID.

> That should be "modified EUI-64 format"

The proposed 4rd address format introduces, for unicast IPv6 addresses, a new variant of the "modified EUI-64" IID format 
It comes in addition to variants so far defined, namely:
- One with u = 0, for the IID privacy option (RFC 4941). 
- One with u = 1, for universal IIDs that embed IEEE OUIs and have g = 0 or unicast addresses (Appendix A of RFC 4291).  

This proposal is expected to be fully in line with the openness expressed in RFC 4291 by saying "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".
While reserved OUIs is one way to use this openness, reserved IID prefixes having u=g=1 is another. 

> just delete the sentence.

OK.
Deleting the sentence in the draft shouldn't be a problem at all. 
It was intended as a clarification for 6man, but doesn't add any technical content.

> This sentence too can be deleted before RFC publication.

OK.

> as far as I can see. I think that is what you should ask for (from

As explained above, "globally unique multicast" isn't suitable for a globally unique _unicast_ address.

If I may add a detail: the proposed new IANA registry would contain IID prefixes that, in the context of IETF modified EUI-64,  have universal scope and don't embed IEEE OUIs. The first one would be the 4rd mark 0300::/8. Others to come may have different lengths (but at least 8 to include u and g bits)

Best regards,
RD

> 
> Regards
>   Brian Carpenter
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Tue, 11 Dec 2012 16:18:15 -0800

Rémi,

Like Brian, I am also trying to understand this.  

My initial personal conclusion to answer Suresh's question, I don't think this is compatible with the IPv6 address architecture.  

It proposes to change how interface IDs are constructed (the use of the "g" and "i" bits in the modified EUI-64) and sets up a new IANA registry (it's not clear to me what else would need to be registered).  This like a very large change for a document that is intended for Experimental status.  Making these changes would seem to me more reasonable after the experiment is completed.  

Given this is a tunneling based solution, why not just add a destination header that includes the information you need to make this approach stateless?  Then you wouldn't have to change the way IPv6 interface identifiers are created and avoid any unintended consequenses.

Further, I thought we already had solutions to providing IPv4 connectivity over IPv6 (there are some large operators doing this today).  The rhetorical question is why do we need more?

Thanks,
Bob

---

From: Rémi Després <[email-masked]>
Date: Wed, 12 Dec 2012 11:08:23 +0100

Hi, Bob,

Please see inline further explanations, and answers to your questions.

2012-12-12 01:18, Bob Hinden <[email-masked]>:

> It proposes to change how interface IDs are constructed (the use of the "g" and "i" bits in the modified EUI-64) and sets up a new IANA registry (it's not clear to me what else would need to be registered).  

Note that it is just a backward-compatible extension, not a change that would imply on anything existing today.
 It takes advantage of an unused combination of bits to introduce a specific way "to allow development of future technology that can take advantage of interface identifiers with universal scope", as envisaged in RFC 4291 itself.
 Appendix A of RFC 4291 "provides examples on the creation of Modified EUI-64 format-based interface identifiers". The two of them that apply to links having universal scope IIDs (i.e. having u = 1) are based on IEEE EUI-64 and IEEE EUI-48 at link layer. Both have g=0 (unicast addresses) so that u=g=1 remains as an escape pattern for new universal-scope formats. 
 Advantage of this escape pattern over using a reserved OUI in the IEEE EUI-64 format, a technique mentioned by Brian in his las t mil, is that it leaves 62 free bits instead of 40. As 4rd needs 48 bits for its own use (an IPv4 address and a 16-bit checksum neutrality preserver), it is the first design that needs the escape pattern. It leaves plenty of space for other uses of this pattern.

> This like a very large change for a document that is intended for Experimental status. Making these changes would seem to me more reasonable after the experiment is completed.

 No change of RFC 41 is AFAIK needed:
(a) RFC 5214, and RFC 4214 before it, already specify an IID format that, being a backward-compatible use of RFC-4291 format, didn't lead to a modification of RFC 4291.
(b) IANA does list in its registries assigned numbers of experimental RFCs.   

> Given this is a tunneling based solution, why not just add a destination header that includes the information you need to make this approach stateless?  Then you wouldn't have to change the way IPv…

All of this has been carefully reviewed in Softwire, and even more so by the six co-authors of widely different origins. No alternative has been found with the same desired combination of functional properties.

> Further, I thought we already had solutions to providing IPv4 connectivity over IPv6 (there are some large operators doing this today).  The rhetorical question is why do we need more?

The need for a _stateless_ solution to assign _public_ IPv4 addresses across IPv6-only domains, including shared IPv4 addresses, has been abundantly discussed and approved in Softwire.
 While MAP-E is now the path chosen for standard track, the WG has found enough complementary functional properties in two other solutions to proceed with them on experimental track, 4rd and MAP-T.  

Hoping to have given the expected clarifications and answers,
Best regards,
RD

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Dec 2012 11:45:39 +0000

I think the only way to make progress on this question is to
discuss two points in a much more general way:

1. Does the current mapping of the "u" bit in the modified EUI format have any value?

2. Does the current mapping of the "g" bit in the modified EUI format have any value?

If the answer to these questions is "no" we could start by saying that they
are *not* mapped from an IEEE EUI into a modified EUI, and then consider
how to use them in future.

Regards
   Brian

---

From: Rémi Després <[email-masked]>
Date: Wed, 12 Dec 2012 14:59:13 +0100

> how to use them in future.

Agreed that this issue introduces an opportunity to clarify the general picture.

Not sure however that the two proposed questions are clear enough because today:
- some IIDs have u = 0, and some have u = 1,
- some IIDs have g = 0, and some have g = 1. 
The only combination that isn't used is u=g=1.

A point that is relevant, I think, is that local-scope IIDs, having u = 0, have any values in the 63 other bits. Despite the name "modified EUI-64", these values aren't constrained in any way by the IEEE EUI-64 format.

The natural conclusion I see is that IETF is free to define any new IID formats that have u=g=1. 
IEEE isn't concerned more than it was when IETF specified the privacy option with u = 0.

Would this be acceptable?

Regards,
RD

---

From: Ole Trøan <[email-masked]>
Date: Wed, 12 Dec 2012 22:32:58 +0100

> how to use them in future.

or we could consider the interface-id as 64 bits without any implied meaning attached to
any of the bits.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Dec 2012 08:13:23 +0000

> or we could consider the interface-id as 64 bits without any implied meaning attached to

We could certainly discuss that, but first I'd like to understand if the mapping
of the u/g bits into layer 3 addresses has any value in practice.

I believe it's true that the u bit has no value for ILNP. At one point there was
a thought that it had potential value for 8+8. Maybe Ran Atkinson can comment.

Does the g bit have any value in multicast? (Obviously it has value in the MAC address,
but here we are talking about the IP address.)

    Brian

---

From: Ole Trøan <[email-masked]>
Date: Thu, 13 Dec 2012 09:24:25 +0100

Brian,

> a thought that it had potential value for 8+8. Maybe Ran Atkinson can comment.

that's my reading of ILNP as well. the interface-id must be unique within your locator set, but that's no
different than how IPv6 works today.

> but here we are talking about the IP address.)

as far as I know, none of our implementations do anything based on the values of the u/g bits.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Thu, 13 Dec 2012 10:13:40 +0100

> but here we are talking about the IP address.)

IPv6 unicast addresses having the group bit set to 1 *already exist* (with the privacy option where all bits other than u=0 can take any values). 
It is therefore ONLY the IPv6-address multicast prefix that determines that an IPv6 address is multicast.
(In my understanding, this doesn't depend on any original thoughts about possible other uses of the g bit.)

Another point is that, in RFC 4291, interface IDs are introduced ONLY for unicast addresses. For multicast addresses, what is introduced is Group IDs. 
IPv6 group IDs have no link, in any RFC that I know, with IIDs. (And even less with modified EUI-64). 

RD