Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt]

From: Usman Latif <[email-masked]>
Date: Sat, 9 Feb 2013 13:16:45 +1100

Hi Remi,

A few months ago, I raised some concerns around RFC 6164 which permitted use of /127 prefixes on inter-router p2p links.
You mention use of u/g bits and reserved IID range for 4rd
Don't you think that network operators who have by now implemented 6164 based addressing in their networks would end up having to readdress portions of their network where they intend to implement 4rd?

Rgds,
Usman

Date: Fri, 8 Feb 2013 16:51:19 +0100
From: R?mi Despr?s <[email-masked]>
To: Havard Eidnes <[email-masked]>
Cc: [email-masked]
Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=iso-8859-1

Le 2013-02-08 ? 11:59, Havard Eidnes <[email-masked]> a ?crit :

>>> However, there is nothing which enforces RFC4291-conforming IIDs for
>>> (for instance) statically configured IPv6-addresses.
>>> So in what way do
>>> well defined u/g values for RFC4291-conforming IIDs help you?
>> 
>> 1.
>> Users that manually configure their IPv6 addresses should be
>> knowledgeable about what they do.
>> 
>> If one configures an address has u=g=1, unless it is for an
>> experiment, it is a human mistake (it conflicts with the IPv6
>> addressing architecture of RFC 4291). Depending on the context,
>> this mistake will have no consequence or will eventually have
>> to be corrected.
> 
> What's the operational failure mode?  Does it fail in a way which
> would be obvious to the ones who has made this mistake, or will
> simply some seemingly-random pairs of hosts fail to communicate?
> I think it would be an engineering mistake to willfully create
> hard-to-detect failure scenarios via a modification to already
> fielded standards.

FULL AGREEMENT that we don't want to modify any "already fielded standard".
If you believe such a change is needed for 4rd, PLEASE EXPLAIN. 

If one configures an address that doesn't follow configuration constraints, it may fail in various ways, but under its own responsibility.
For instance, if it has the wrong subnet prefix, it won't be reachable from across the Internet, like what may happen if it has a non-RFC4291-complying IID that happens to be in the 4rd reserved range in a site where 4rd is activated.

> 
>> Note that, even if one does such a mistake in a 4rd site, the
>> likelihood of using the 4rd IID prefix 0x0300 remains low.
> 
> That's a nice handwave...

This is a fact, worth noting IMHO, especially since the particular example of a non RFC4291-compliant address Ole gave didn't conflict with 4rd.

Your lack of interest for this point doesn't justify, IMHO, a so depreciating comment. 

>> 2.
>> On my home network, I know nobody is doing manual configuration.
> 
> That doesn't really prove anything.

It doesn't prove anything, OK, and wasn't BTW claimed to prove anything in particular.

Yet, the risk of manual misconfigurations that may conflict with the RFC 4291, which is indeed a risk, is mitigated by the fact that manual address configuration is AFAIK more an exception than a general practice.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Sat, 9 Feb 2013 10:16:49 +0100

Hi, Usman,

Thank you for this opportunity to clarify once more an important point.

> Don't you think that network operators who have by now implemented 6164 based addressing in their networks would end up having to readdress portions of their network where they intend to implement…

The reason why no readdressing will be needed is tat RFC 6144 only concerns inter-router links. Their /127 IPv6 prefixes are distinct from those used with 64-bit IIDs.

Incidentally, I wrote myself:
- "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" (ref.  http://www.ietf.org/mail-archive/web/ipv6/current/msg16988) 
- "For addresses that aren't subject to SLAAC like, for instance, those of inter-router links of RFC6164, the RFC4291 structure of /64 IIDs isn't applicable. A clarification on this would IMHO be useful." (ref. http://www.ietf.org/mail-archive/web/ipv6/current/msg17023).

Regards,
RD

---

From: Usman Latif <[email-masked]>
Date: Sun, 10 Feb 2013 14:43:48 +1100

Hi Remi,

> The reason why no readdressing will be needed is tat RFC 6144 only concerns inter-router links. Their /127 IPv6 prefixes are distinct from those used with 64-bit IIDs.

So if I understand it correctly, if a PE-CE link already has a /127 prefix assigned to it- and we wanted to use the CE as a 4rd CE, we'll have to assign an additional IPv6 prefix to the CE with 64-bit IIDs?

Pls share little detail with me in a scenario where a SP already has /127 with CEs and 4rd is needed from the CE

thanks,
Usman

---

From: "Miya Kohno (mkohno)" <[email-masked]>
Date: Sun, 10 Feb 2013 11:45:53 +0000

Hi Usman,

/127 addressing and SLAAC is mutually exclusive, so I think it's out of the scope of the problem, where we discuss if u/g bit should be meaningful also for non-EUI-derived address.

Miya

From: Usman Latif <[email-masked]<mailto:[email-masked]>>
Date: Sunday, February 10, 2013 12:43 PM
To: Rémi Després <[email-masked]<mailto:[email-masked]>>
Cc: 6man 6man-wg <[email-masked]<mailto:[email-masked]>>, "Miya Kohno (mkohno)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt]

Hi Remi,

thanks,
Usman

On 09/02/2013, at 8:16 PM, Rémi Després <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Usman,

2013-02-09 03:16, Usman Latif <[email-masked]<mailto:[email-masked]>> :

Hi Remi,

Regards,
RD

Rgds,
Usman

Date: Fri, 8 Feb 2013 16:51:19 +0100
From: R?mi Despr?s <[email-masked]<mailto:[email-masked]>>
To: Havard Eidnes <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt]
Message-ID: <[email-masked]<mailto:[email-masked]>>
Content-Type: text/plain; charset=iso-8859-1

Le 2013-02-08 ? 11:59<x-apple-data-detectors://41>, Havard Eidnes <[email-masked]<mailto:[email-masked]>> a ?crit :

1.

2.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 11 Feb 2013 11:13:04 +0100

Hi, Bob, Ole,

RFC 6164 (/127 on inter-router links) is in fact an update of RFC4291 (IPv6 addressing architecture).
Yet, it isn't listed as such in https://tools.ietf.org/html/rfc4291.
Shouldn't this be fixed?

Regards,
RD

PS: This point has been noted during the discussion below concerning 4rd CEs and u/g bits of IIDs.: 

2013-02-10 04:43, Usman Latif <[email-masked]> 
...
> Pls share little detail with me in a scenario where a SP already has /127 with CEs and 4rd is needed from the CE

According to RFC 6164, /127 prefixes are used ONLY on inter-router link. 
They cannot be used as customer-site IPv6 prefixes which, to comply with https://tools.ietf.org/html/rfc4291#section-2.5.1, MUST permit 64-bit IIDs. 

Each 4rd CE MUST therefore be delegated at least one IPv6 prefix having at most 64 bits (this doesn't depend on its WAN link having or not a /127). 

RD

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Feb 2013 10:55:21 +0000

(Correcting the Subject header)

That could be reported as an erratum against RFC 6164.

Regards
   Brian

On 11/02/2013 10:13, Rémi Després wrote:
> ------------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Rémi Després <[email-masked]>
Date: Mon, 11 Feb 2013 12:05:02 +0100

Le 2013-02-11 à 11:55, Brian E Carpenter <[email-masked]> a écrit :

> (Correcting the Subject header )
Oops, 6144 instead of 6164 was a typo!

> That could be reported as an erratum against RFC 6164.

IN ADDITION to citing RFC 6164 as updating RFC 4291, this makes sense to me.

Thanks,
RD

---

From: "George, Wes" <[email-masked]>
Date: Mon, 11 Feb 2013 08:32:37 -0500

> IN ADDITION to citing RFC 6164 as updating RFC 4291, this makes sense to

[WEG] FWIW, I suggested the erratum route when I realized that 6164 also failed to take obsolete 3627, and was told by IESG that I needed to write a short draft, hence 6547. Wish someone had brought up 4291 at the time when the draft of 6547 was being reviewed...

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Usman Latif <[email-masked]>
Date: Tue, 12 Feb 2013 09:51:02 +1100

Hi Remi,

On 11/02/2013, at 9:13 PM, Rémi Després <[email-masked]> 
> Each 4rd CE MUST therefore be delegated at least one IPv6 prefix having at most 64 bits (this doesn't depend on its WAN link having or not a /127). 

Yes 6164 is only for inter-router links
I was under the impression that 4rd CE might use the WAN IPv6 address for stateless tunnelling of IPv4 inside IPv6
Maybe this was a misunderstanding(?)
Or is it really upto the operator whether he wants to leverage the CE WAN IPv6 prefix or the allocated IPv6 prefix routed to the CE site
If the CE WAN happens to be a /64 prefix, could the 4rd leverage that?
What is the recommendation there

Regards,
Usman

---

From: Rémi Després <[email-masked]>
Date: Tue, 12 Feb 2013 09:58:20 +0100

> Maybe this was a misunderstanding(?)

In the 4rd specification, CE IPv6 prefixes are at most /64.
See Figure 5 in particular:

   +----------+---+-+-+------+---+     +--------------+-+-+------+---+
   |CE v6 prfx| 0 |V|0|v4 add|CNP|     |BR IPv6 prefix|V|0|v4 add|CNP|
   +----------+-|-+-+-|+-----+---+     +--------------+-+-+------+---+
   :   =<64   : | :8:8:  32  :16 :     :      64      :8:8:  32  :16 :
                |
          Padding to /64

RD