Subject: RE: Moving RFC4291-bis forward

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 27 Nov 2018 21:51:43 +0000

Can anyone tell me what is the status of this effort? It appears that the
draft expired many months ago - has the effort itself been abandoned?

Thanks - Fred

---

From: Ole Troan <[email-masked]>
Date: Wed, 28 Nov 2018 09:50:36 +0100

Fred,

> draft expired many months ago - has the effort itself been abandoned?

You can find the document status here:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4291bis/

WG state: Parked WG Document

Cheers,
Ole

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 28 Nov 2018 17:39:47 +0000

Great, but what does "Parked" mean? In particular, are there any plans to
un-park it at some point?

Thanks - Fred

> -----Original Message-----
> From: Ole Troan [mailto:[email-masked]]
> Sent: Wednesday, November 28, 2018 12:51 AM
> To: Templin (US), Fred L <[email-masked]>
> Cc: 6man WG <[email-masked]>
> Subject: Re: Moving RFC4291-bis forward
> 
> Fred,
>

---

From: Ole Troan <[email-masked]>
Date: Wed, 28 Nov 2018 20:03:57 +0100

Fred,

> un-park it at some point?

Aren’t we collectively sitting on our hands waiting for it to accumulate enough parking tickets to get towed? :-)

Cheers,
Ole

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 28 Nov 2018 14:20:33 -0500

Hi Fred, 

On Wed, Nov 28, 2018, 12:40 PM Templin (US), Fred L <[email-masked] <mailto:[email-masked]>> wrote:
Great, but what does "Parked" mean? In particular, are there any plans to
un-park it at some point?

Given that the IETF last call showed a deep split in the community with irreconcilable differences, repeating the process over is not going to end with a different result. Do you think something has changed since then (e.g. Do you think there is some new variation of text that can gain consensus)?

Thanks
Suresh

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Nov 2018 08:36:27 +1300

> Given that the IETF last call showed a deep split in the community with irreconcilable differences, repeating the process over is not going to end with a different result. Do you think something ha…

Suresh,

The only way I can think of changing the situation is to agree to remove
/64 from 4291bis completely, and move it to a new short draft, which would
then soon enter the same parked state. This would have the advantage of
allowing us to fix all the non-contentious glitches in 4291, but would
not solve the split at all.

   Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 28 Nov 2018 20:37:41 +0100

Le 28/11/2018 à 20:36, Brian E Carpenter a écrit :
> /64 from 4291bis completely,

I agree.

Alex

  and move it to a new short draft, which would
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 28 Nov 2018 19:38:56 +0000

HI Suresh,

I am coming at this from a different angle than the impasse you are referring to.
My case is that, if an rfc4291(bis) were to move forward, then there is a new IPv6
address type that I would like to propose for inclusion. But, again, that is aside
from any of the earlier discussions.

Thanks - Fred

From: Suresh Krishnan [mailto:[email-masked]]
Sent: Wednesday, November 28, 2018 11:21 AM
To: Templin (US), Fred L <[email-masked]>
Cc: Ole Trøan <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Moving RFC4291-bis forward

Hi Fred,
On Wed, Nov 28, 2018, 12:40 PM Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Great, but what does "Parked" mean? In particular, are there any plans to
un-park it at some point?

Thanks
Suresh

---

From: 神明達哉 <[email-masked]>
Date: Wed, 28 Nov 2018 11:48:11 -0800

At Thu, 29 Nov 2018 08:36:27 +1300,
Brian E Carpenter <[email-masked]> wrote:

> > Given that the IETF last call showed a deep split in the community with
irreconcilable differences, repeating the process over is not going to end
with a different result. Do you think something has changed since then
(e.g. Do you think there is some new variation of text that can gain
consensus)?

> not solve the split at all.

I wonder what happened to draft-farmer-6man-exceptions-64.  I thought
it was an attempt to achieve something similar to what you said
above.  There was some discussion, and if I remember it correctly it
didn't (yet) show irreconcilable differences, but somehow everyone
seems to have forgotten it...

BTW, in any case I don't think we can introduce any new types of IPv6
addresses to rfc4291bis as long as it's supposed to be a promotion
of RFC4291 from DS to IS.

--
JINMEI, Tatuya

---

From: Fred Baker <[email-masked]>
Date: Wed, 28 Nov 2018 11:51:02 -0800

I just sent a note, and then observed this email. Speaking from the position of a fly on the wall, I might suggest that you describe the address type you want in an internet draft and let the working group comment on it independent of the architecture.

> On Nov 28, 2018, at 11:38 AM, Templin (US), Fred L <[email-masked]> wrote:
> 
> HI Suresh,
> 
> From: Suresh Krishnan [mailto:[email-masked]]
> On Wed, Nov 28, 2018, 12:40 PM Templin (US), Fred L <[email-masked]> wrote:

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: Lee Howard <[email-masked]>
Date: Wed, 28 Nov 2018 15:50:24 -0500

>> Given that the IETF last call showed a deep split in the community with irreconcilable differences, repeating the process over is not going to end with a different result. Do you think something h…

Sometime consensus just changes over time. We could check again.

> not solve the split at all.

Can you write it in such a way that the newly-parked draft is not a 
normative? That is, won't this document just get blocked by the new doc?

Lee

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 28 Nov 2018 13:37:54 -0800

> Sometime consensus just changes over time. We could check again.

I don't think we should do that. The previous check was very recent, it was
extremely expensive in terms of number of emails and community time, and it
resulted in no progress.

---

From: Mark Smith <[email-masked]>
Date: Thu, 29 Nov 2018 09:14:29 +1100

>From memory, the arguments from the objectors were mischaracterising
what the 64 bit IID is, asserting it to be a hard boundary between the
network and IID portions ("classful" was one of the terms being
used.). RFC6164 (/127s on p2p inter-router links) would be impossible
if that was the case. One of the objectors should know it isn't a hard
boundary because they're also an author of RFC6164.

BCP198 is effectively another statement that 64 bit IIDs are not
creating a hard boundary at the 64th bit.

::1/128 is more evidence that there is no hard boundary at the 64th bit.

IPv6 would have clearly distinct network and IID address fields in its
RFC 8200 specified header if there was a hard boundary between them
(as e.g. Novell IPX and Appletalk's DDP do).

64 bit IIDs are a "soft boundary", a convention and a common default
relied upon by many RFCs and implementations. If the opponents of
RFC4291bis won't accept that, continuing to assert it is a hard
boundary, then I don't think consensus will ever be achieved.

Pity, because the goal of RFC4291bis was editorial updates, cleanups
and clarifications, nothing more and nothing new.

Regards,
Mark.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 28 Nov 2018 15:20:57 -0800

Suresh,

> On Nov 28, 2018, at 11:20 AM, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Fred,
> 

That my take too.   As you noted, the issue came up in IETF Last call, we did get consensus in the w.g.  Discussing it here isn’t very likely to get a different outcome.

It would have been nice to advance it, there were lots of other things in the BIS that were useful.

Bob

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 28 Nov 2018 16:05:51 -0800

On Wed, Nov 28, 2018 at 3:21 PM Bob Hinden <[email-masked]> wrote:

> That my take too.   As you noted, the issue came up in IETF Last call, we
> did get consensus in the w.g.  Discussing it here isn’t very likely to get
> a different outcome.
>

The problem was that one set of people strongly objected to advancing it
unless the text on /64 was changed, and another set of people strongly
objected to changing the text. I don't think that will change.

I suppose one thing we haven't tried is attempt a 4291bis that does not
change the text on /64 but also does not advance to full standard. That
would at least get us "the other things in the BIS that were useful". I'm
not particularly hopeful that that would gain consensus though.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 29 Nov 2018 14:49:57 +0100

Le 28/11/2018 à 23:14, Mark Smith a écrit :
>>>> On Wed, Nov 28, 2018, 12:40 PM Templin (US), Fred L
>>>> <[email-masked] <mailto:[email-masked]>>
>>>> wrote: Great, but what does "Parked" mean? In particular, are
>>>> there any plans to un-park it at some point?
>>>> 
>>>> Given that the IETF last call showed a deep split in the
>>>> community with irreconcilable differences, repeating the
>>>> process over is not going to end with a different result. Do
>>>> you think something has changed since then (e.g. Do you think
>>>> there is some new variation of text that can gain consensus)?
>> 
> what the 64 bit IID is, asserting it to be a hard boundary between
> the network and IID portions ("classful" was one of the terms being 
> used.). RFC6164 (/127s on p2p inter-router links) would be
> impossible if that was the case. One of the objectors should know it
> isn't a hard boundary because they're also an author of RFC6164.
> 
> IPv6 would have clearly distinct network and IID address fields in
> its RFC 8200 specified header if there was a hard boundary between
> them (as e.g. Novell IPX and Appletalk's DDP do).
> 
> relied upon by many RFCs and implementations.

One is right to call it "soft 64" in that there are many exceptions as 
mentioned above.

However, one key point where that boundary is harder than expected is in 
SLAAC prefix+IID.  Even if the SLAAC spec leaves the prefixlen open, and 
one can intepret RFC4291 64 number as a "soft 64" (because exceptions), 
it is still a boundary (some SLAAC software calls "violation" a 65 in RA).

It is a hard (not soft) boundary in growing the Internet at the edges. 
There is no IPv6 device on the market today that cleanly extends the 
network at the edges.  One either gets NAT-IPv6 or 64share, none of 
which being good practices.  Few router devices are capable of 
DHCPv6-PD, and a major modem manufacturer insists on calling '64' a key 
design of IPv6.

So, yes, it is a soft limit (in that there are many exceptions) but it 
is a little harder than just soft.

Alex

  If the opponents of
> Regards, Mark.
>>> The only way I can think of changing the situation is to agree to
>>> remove /64 from 4291bis completely, and move it to a new short
>>> draft, which would then soon enter the same parked state. This
>>> would have the advantage of allowing us to fix all the
>>> non-contentious glitches in 4291, but would not solve the split
>>> at all.
>> 
>> Can you write it in such a way that the newly-parked draft is not
>> a normative? That is, won't this document just get blocked by the
>> new doc?
>> 
>> Lee
>> 
>> 
>>> 
>>> Brian
>>> 
>>> [email-masked] Administrative Requests:
>>> https://www.ietf.org/mailman/listinfo/ipv6 
>> IETF IPv6 working group mailing list [email-masked] Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Lee Howard <[email-masked]>
Date: Thu, 29 Nov 2018 10:25:57 -0500

> That my take too.   As you noted, the issue came up in IETF Last call, we did get consensus in the w.g.  Discussing it here isn’t very likely to get a different outcome.

I'm rereading the IETF LC thread from February 2017 (21 months ago), and 
I'm not convinced the differences are irreconcilable, and if the are 
reconcilable, then the WG can discuss text changes to respond to the 
objections.

https://mailarchive.ietf.org/arch/search/?q=rfc4291bis&f_list=ietf

Everyone agrees:

  * /64 is generally required for SLAAC
  * /64 applies, at most, to 2000::/3
  * There are many ways to number interfaces/create IIDs, many of which
    recognize no /64 boundary

Some folks described the /64 boundary as operational guidance. I'd 
settle for Brian's idea of calling out an operational/implementation 
guidance doc describing IID considerations. There was discussion of what 
such a document might say.

I think the last couple of days of discussion in that thread were 
productive consideration of proposed alternative text. It would take me 
a few hours to go through the thread to pull out all of the proposed 
text and the arguments for and against, but I think it's possible.

Lee

---

From: Bob Hinden <[email-masked]>
Date: Thu, 29 Nov 2018 09:27:44 -0800

Lee,

> On Nov 29, 2018, at 7:25 AM, Lee Howard <[email-masked]> wrote:
> 
> 
>>> <[email-masked]>
>>>  wrote:
> I'm rereading the IETF LC thread from February 2017 (21 months ago), and I'm not convinced the differences are irreconcilable, and if the are reconcilable, then the WG can discuss text changes       to respond to the objections.
> 
> 	• /64 is generally required for SLAAC
> 	• /64 applies, at most, to 2000::/3
> 	• There are many ways to number interfaces/create IIDs, many of which recognize no /64 boundary
> Some folks described the /64 boundary as operational guidance. I'd settle for Brian's idea of calling out an operational/implementation guidance doc describing IID considerations. There was discussion of what such a document might say.
> I think the last couple of days of discussion in that thread were productive consideration of proposed alternative text. It would take me a few hours to go through the thread to pull out all of the proposed text and the arguments for and against, but I think it's possible.

Suggest you look at the text in the last version published (https://www.ietf.org/archive/id/draft-ietf-6man-rfc4291bis-09.txt) and propose changes.   If you can get agreement here, then you could talk to the people who raised issues in the IETF last call and see if they are OK with the new text.

Bob

>>> Administrative Requests:
>> Administrative Requests:

---

From: Ole Troan <[email-masked]>
Date: Thu, 29 Nov 2018 19:34:36 +0100

> 	• There are many ways to number interfaces/create IIDs, many of which recognize no /64 boundary

I am not sure there is even consensus around that. “Everyone agrees” statements have a tendency to make people look for reasons to disagree. ;-)

While finishing the work, and making the addressing architecture full standard is a noble cause.
Unless you want something fundamentally changed, there is little too gain I would have thought.

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 29 Nov 2018 17:51:43 -0300

On 28/11/18 17:50, Lee Howard wrote:
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>> Given that the IETF last call showed a deep split in the community
>>> with irreconcilable differences, repeating the process over is not
>>> going to end with a different result. Do you think something has
>>> changed since then (e.g. Do you think there is some new variation of
>>> text that can gain consensus)?
> 

ONe might argue that the requirement on /64 has nothing to do with the
architecture, but with SLAAC. In that case, rfc4291bis wouldn't even
reference this I-D, and the I-D in question might e.g. just update, say,
RFC4862.

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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 29 Nov 2018 21:13:20 +0000

Hi, 'draft-templin-6man-aeroaddr' outlines an IPv6 link-local address type known
as the AERO Address (see below). It is only used on links that assume /64, and only
on links where all nodes on the link honor the scheme. The scheme  can be used on
any link type, i.e., and not just one specific link type. Comments?

---

3.  The AERO Address

   An AERO address is an IPv6 link-local address with an interface
   identifier based on a prefix that has been delegated to a node for
   its own exclusive use.

   For IPv6, AERO addresses begin with the prefix fe80::/64 and include
   in the interface identifier (i.e., the lower 64 bits) a 64-bit prefix
   taken from the node's delegated IPv6 prefix.  For example, if the
   node obtains the IPv6 delegated prefix 2001:db8:1000:2000::/56 it
   constructs its corresponding AERO addresses as:

      fe80::2001:db8:1000:2000

      fe80::2001:db8:1000:2001

      fe80::2001:db8:1000:2002

      ... etc. ...

      fe80::2001:db8:1000:20ff

   For IPv4, AERO addresses are based on an IPv4-mapped IPv6 address
   [RFC4291] formed from the node's delegated IPv4 prefix.  For example,
   for the IPv4 prefix 192.0.2.16/28 the IPv4-mapped AERO addresses are:

      fe80::FFFF:192.0.2.16

      fe80::FFFF:192.0.2.17

      fe80::FFFF:192.0.2.18

      ... etc. ...

      fe80:FFFF:192.0.2.31

   Administratively-provisioned AERO addresses are allocated from the
   range fe80::/96, and MUST be managed for uniqueness by the
   administrative authority for the link.  For interfaces that assign
   IPv4 addresses, the lower 32 bits of the AERO address includes the
   IPv4 address, e.g., for the IPv4 address 192.0.2.1 the corresponding
   AERO address is fe80::192.0.2.1.  For other interfaces, the lower 32
   bits of the AERO address includes a unique integer value, e.g.,
   fe80::1, fe80::2, fe80::3, etc.  (Note that the address fe80:: is
   reserved as the IPv6 link-local Subnet Router Anycast address
   [RFC4291], and the address fe80::ffff:ffff is reserved for special-
   purposes; hence, these values are not available for administrative
   assignment.)

   AERO addresses that embed an IPv6 prefix can be statelessly
   transformed into an IPv6 Subnet Router Anycast address [RFC4291] and
   vice-versa.  For example, for the AERO address
   fe80::2001:db8:2000:3000 the corresponding Subnet Router Anycast
   address is 2001:db8:2000:3000::, and for the IPv6 Subnet Router
   Anycast address 2001:db8:1:2:: the corresponding AERO address is
   fe80::2001:db8:1:2.

---

From: Lee Howard <[email-masked]>
Date: Thu, 29 Nov 2018 17:40:55 -0500

Since the original purpose of 4291-bis was to advance it to full 
standard, I would not want to add a brand new address type to it. A new 
address based on a draft would hold publication until the new draft was 
ready for publication and there were multiple interoperable implementations.

This draft can update, without obsoleting, a final rfc4291.

Lee