Subject: Subject: Confirming consensus on adopting draft-carpenter-6man-why64

From: Ole Troan <[email-masked]>
Date: Wed, 5 Mar 2014 10:20:18 +0000

There was consensus to adopt ￼￼draft-carpenter-6man-why64 as a 6MAN working group item at the IETF89 working group meeting, with the expectation that the document is changed to making a positive statement as opposed to a defensive one.
This is a call to confirm that consensus on the mailing list.

If you object to adopting this document please state so, as well as your reasons.

This call will end on 2014-03-12.

Best regards,
Ole and Bob

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Mar 2014 12:10:22 +0100

I support it.

[email-masked]

---

From: Roland Bless <[email-masked]>
Date: Wed, 05 Mar 2014 13:35:31 +0100

Hi,

On 05.03.2014 11:20, Ole Troan wrote:
> There was consensus to adopt ￼￼draft-carpenter-6man-why64 as a 6MAN
> working group item at the IETF89 working group meeting, with the
> expectation that the document is changed to making a positive
> statement as opposed to a defensive one. This is a call to confirm
> that consensus on the mailing list.

I support adoption of the draft.

Regards,
 Roland

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 5 Mar 2014 15:33:08 +0000

I support adoption.

Lorenzo
On 5 Mar 2014 10:20, "Ole Troan" <[email-masked]> wrote:

> expectation that the document is changed to making a positive statement as
> opposed to a defensive one.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 5 Mar 2014 16:49:37 +0000

support

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Wednesday, March 05, 2014 10:20 AM
To: 6man WG
Subject: Subject: Confirming consensus on adopting draft-carpenter-6man-why64

Best regards,
Ole and Bob

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 5 Mar 2014 11:56:29 -0600

I support the adoption.

Regards,

Behcet

---

From: Philip Matthews <[email-masked]>
Date: Thu, 6 Mar 2014 11:46:37 +0000

Support

---

From: Ole Troan <[email-masked]>
Date: Thu, 6 Mar 2014 13:19:31 +0000

just to emphasise what was called for:

"If you object to adopting this document please state so, as well as your reasons."

there is no need to post "+1" comments on this call.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 6 Mar 2014 13:21:57 +0000

> "If you object to adopting this document please state so, as well as your

That by itself does not make it clear that you were ONLY interested in
objections and not in statements of support.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 6 Mar 2014 15:07:38 -0800 (PST)

I support adoption.

----- Original Message -----
> From: Ole Troan <[email-masked]>
> To: 6man WG <[email-masked]>
> Cc: 
> Sent: Wednesday, 5 March 2014 9:20 PM
>T here was consensus to adopt ￼￼draft-carpenter-6man-why64 as a 6MAN working 
> group item at the IETF89 working group meeting, with the expectation that the 
> document is changed to making a positive statement as opposed to a defensive 
> one.

---

From: David Farmer <[email-masked]>
Date: Thu, 06 Mar 2014 19:18:03 -0600

On 3/5/14, 04:20 , Ole Troan wrote:
> There was consensus to adopt draft-carpenter-6man-why64 as a 6MAN working group item at the IETF89 working group meeting, with the expectation that the document is changed to making a positive statement as opposed to a defensive one.

First, I support WG adoption of the draft.  However I'm concerned by 
proviso "with the expectation that the document is changed to making a 
positive statement as opposed to a defensive one."

I guess my concern is positive in which way, and not defensive of what? 
  It sound like the conclusion section is being specified, but as I was 
unable to participate in the WG meeting, I'm not sure what conclusion is 
being pushed?  That 64 bit IIDs are the right size.  Or, that we should 
allow different IID sizes.  Or, something else.

Personally, I very much like the neutral stance the draft currently has. 
  While, I don't think we need to rush off changing anything quickly, 
and 64 is a fine default for the vast majority of situations.  However, 
I'm also very suspicious of one size fits all dictums.

I'd like to see the idea of extremely short IIDs discouraged, maybe even 
a little more than the draft already does, IIDs of 16 bits or less (/112 
or longer prefixes) are a bad idea in most cases, except for 
point-to-point links and other special situations.  But, I also cannot 
in good conscience say that the world will come to an end if people 
steal a couple nibbles off the default 64 bit IID size and go with IIDs 
of 60, 56, or 48 bits.

I think keeping IIDs nibble aligned would be a GREAT operational 
operational recommendation.

The idea the EUI-64 will make a good IIDs in most typical situations has 
been shot down by privacy concerns.  They should remain valid IIDs, but 
they SHOULD NOT be the default IID for typical Internet user devices, 
but that's a different issue and draft.

Also, as Brian noted there is operational demand, valid or not, for IIDs 
shorter than 64, or prefixes longer than /64.

So, I'd prefer a conclusion with a strong recommendation that 64 bits 
SHOULD be the default IID size and any change from the default needs 
extremely careful operational consideration.  However, the intent of the 
IPv6 architecture was for a variable IID size, and so IIDs shorter than 
64 should be ensured in our IPv6 protocol designs and implementations. 
Rather that anointing 64 bit IIDs as the one true IID size.  I'd like to 
see autoconf for IIDs other that 64 bits as well, but that should be a 
longer-term change in the specs in my opinion.

Thanks

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 6 Mar 2014 18:12:07 -0800 (PST)

----- Original Message -----
> From: David Farmer <[email-masked]>
> To: Ole Troan <[email-masked]>; 6man WG <[email-masked]>
> Cc: 
> Sent: Friday, 7 March 2014 12:18 PM
> Subject: Re: Subject: Confirming consensus on adopting draft-carpenter-6man-why64
> 

<snip>

> longer-term change in the specs in my opinion.

This has just reminded me of a comment that might be useful in this draft.

I think a way to describe IPv6 addressing structure is to say that the /64 boundary between the prefix and the IID is a "soft" boundary between the fields, rather than a hard one. They are soft boundaries rather than hard boundaries because forwarding uses a longest match rule on the the whole 128 bits, so the boundaries are there to help simplify, organise and structure addressing, and to facilitate automated address generation and configuration, but not there for forwarding. 

I think forwarding based on the whole 128 bits yet creating soft boundaries for portions of the address space (which may be different for different portions) is for future proofing, so that if the soft boundaries end up being incorrect, they can be changed, without requiring an upgrade to the all of the forwarding devices in the Internet. It is probably fundamentally an outcome of the lessons learned from the effort involved in the change from classful to classless forwarding in IPv4 in the mid 1990s.

Perhaps to further demonstrate this soft boundary difference, it might be worth contrasting IPv6 with RFC791 classful and earlier RFC760 "single class" IPv4 (with IEN115 also making the hard boundary between network and 'local address' field in early IPv4 clear), and perhaps mentioning that other earlier protocols have had distinct network and host/node fields in their addresses, and that the host/node field was only used for forwarding once the packet had reached its final hop.

Regards,
Mark.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 7 Mar 2014 02:32:44 +0000

> From: ipv6 [mailto:[email-masked]] On Behalf Of Mark ZZZ Smith

> I think a way to describe IPv6 addressing structure is to say that the /64
> boundary between the prefix and the IID is a "soft" boundary between the
> fields, rather than a hard one. They are soft boundaries rather than hard
> boundaries because forwarding uses a longest match rule on the the whole 128
> bits, so the boundaries are there to help simplify, organise and structure
> addressing, and to facilitate automated address generation and configuration,
> but not there for forwarding.
> 
> I think forwarding based on the whole 128 bits yet creating soft boundaries
> for portions of the address space (which may be different for different
> portions) is for future proofing, so that if the soft boundaries end up being
> incorrect, they can be changed, without requiring an upgrade to the all of
> the forwarding devices in the Internet. It is probably fundamentally an
> outcome of the lessons learned from the effort involved in the change from
> classful to classless forwarding in IPv4 in the mid 1990s.
> 
> Perhaps to further demonstrate this soft boundary difference, it might be
> worth contrasting IPv6 with RFC791 classful and earlier RFC760 "single class"
> IPv4 (with IEN115 also making the hard boundary between network and 'local
> address' field in early IPv4 clear), and perhaps mentioning that other
> earlier protocols have had distinct network and host/node fields in their
> addresses, and that the host/node field was only used for forwarding once the
> packet had reached its final hop.

I felt the urge to support this text. I think Mark has stated this very well. The assurances that a 64-bit boundary is the right way to go end up sounding a bit near-sighted, and we have those TWO IPv4 precedents to make the point. This text seeks to avoid repeating history, while at the same time urging everyone to keep things simple.

Bert

---

From: Glen Turner <[email-masked]>
Date: Fri, 7 Mar 2014 18:03:18 +1030

> There was consensus to adopt ￼￼draft-carpenter-6man-why64 as a 6MAN working group item at the IETF89 working group meeting, with the expectation that the document is changed to making a positive st…

The specification states that a address prefixes can be in the ranges [0,64], [127]. Thus hardware which is incapable of longest-prefix forwarding into a /124 appears to be compliant. I suggest that if the draft does not intend this then it could explicitly say that longest-prefix forwarding should be possible for all prefix lengths should that once again be required by future specifications.

To assist operators, the draft could discuss migration techniques for networks which do use addressing outside of the permitted range.

To assist designers, the draft could state which takes precedence: this draft, or a configuration protocol or a command line offering configuration of the interface identifier to non-/64.

> 2.  Some have argued that more prefix bits are needed to allow a
>        hierarchical addressing scheme within a campus or corporate
>        network.  However, flat routing is widely and successfully used
>        within rather large networks, with hundreds of routers and
>        thousands of end systems.  Therefore there is no objective need
>        for additional prefix bits to support hierarchy and aggregation.

This claim rather depends upon the robustness of the links to the subnets and thus the desire for route aggregation. A large network based on fibre optics isn’t the worst case, so I am not sure why it is used as the illustrative example. A string of islands connected with wireless links may well have less sanguine views about the desirability of hierarchical addressing in order to allow route aggregation.

In any case, this is an argument for altering the address registry rules to allow larger subnet addressing for these networks, not for altering the size of the interface id (and losing features such as autoconf). Certainly a 32b site level aggregator gives plenty of opportunity for route aggregation whilst still allowing plenty of subnets per site. The “IANA Considerations” section could be updated to suggest larger SLAs be permitted where unavoidable lack of robustness makes route aggregation desirable and the site has too many subnets to allow this to be done in a typical SLA allocation.

Regards to all, glen

-- 
 Glen Turner <http://www.gdt.id.au/~gdt/>

---

From: Ray Hunter <[email-masked]>
Date: Fri, 07 Mar 2014 09:16:41 +0100

I also support adopting the draft, but not a pre-cooked outcome. IMHO 
The full WG process should be allowed to run its course until rough 
consensus is achieved.

IMHO SLAAC is not mandated/anointed as the sole solution for correct 
operation of the IPv6 architecture, and CIDR applies to all 128 bits.

As a side note, people are both creative and paranoid. Sometimes it's 
necessary to force balanced return paths in high availability last-hop 
connections to an semi-trusted partner router (main/standby) without 
dynamic routing e.g. because of middleware boxes that need to see both 
outbound and return packets in a session. One trick in IPv4 is to 
advertise two /25 from one BGP path and a /24 (aggregate) on the other 
into the cloud with equal weights and metrics, and allow CIDR to do it's 
work in one direction, and use HSRP for the return path + a static route 
configured by the semi-trusted partner on their router. I see no reason 
why IPv6 shouldn't be able to repeast the trick with /65 and /64 and 
HSRPv6. Routers ignore RA anyway, security people are paranoid about 
configuring any dynamic routing at all to semi-trusted partners to avoid 
any potential for backbone flapping, and I for one don't want to have an 
outbound static route pointing to a link local that changes every time 
the semi-trusted partner network changes their hardware (unannounced). 
It's a corner case, but I'm sure there are many more similar.

David Farmer wrote:
>> There was consensus to adopt draft-carpenter-6man-why64 as a 6MAN 
>> statement as opposed to a defensive one.
> I guess my concern is positive in which way, and not defensive of 
> what?  It sound like the conclusion section is being specified, but as 
> I was unable to participate in the WG meeting, I'm not sure what 
> conclusion is being pushed?  That 64 bit IIDs are the right size.  Or, 
> that we should allow different IID sizes.  Or, something else.
>
> Personally, I very much like the neutral stance the draft currently 
> has.  While, I don't think we need to rush off changing anything 
> quickly, and 64 is a fine default for the vast majority of 
> situations.  However, I'm also very suspicious of one size fits all 
> dictums.
>
> I'd like to see the idea of extremely short IIDs discouraged, maybe 
> even a little more than the draft already does, IIDs of 16 bits or 
> less (/112 or longer prefixes) are a bad idea in most cases, except 
> for point-to-point links and other special situations.  But, I also 
> cannot in good conscience say that the world will come to an end if 
> people steal a couple nibbles off the default 64 bit IID size and go 
> with IIDs of 60, 56, or 48 bits.
>
> The idea the EUI-64 will make a good IIDs in most typical situations 
> has been shot down by privacy concerns.  They should remain valid 
> IIDs, but they SHOULD NOT be the default IID for typical Internet user 
> devices, but that's a different issue and draft.
>
> Also, as Brian noted there is operational demand, valid or not, for 
> IIDs shorter than 64, or prefixes longer than /64.
>
> extremely careful operational consideration.  However, the intent of 
> the IPv6 architecture was for a variable IID size, and so IIDs shorter 
> than 64 should be ensured in our IPv6 protocol designs and 
> implementations. Rather that anointing 64 bit IIDs as the one true IID 
> size.  I'd like to see autoconf for IIDs other that 64 bits as well, 
> but that should be a longer-term change in the specs in my opinion.
>
> Thanks
>

-- 
Regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Mar 2014 21:59:39 +1300

What I'm getting from this thread is that we should
underline that IPv6 is by design a VLSM architecture and
that all code needs to reflect this (i.e. be capable
of dealing with any prefix length). But that (as the
addressing architecture says) the IID length is currently
required (not recommended) to be 64.

If you use an IID<64 and a prefix>64, you are outside
the specs and results may vary.

If we wanted to say something different from that, this
would need to be a standards track document, which was
not the proposal put to a hum this week.

   Brian

On 07/03/2014 15:12, Mark ZZZ Smith wrote:
> .

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Mar 2014 23:57:47 +1300

> I felt the urge to support this text. I think Mark has stated this very well. The assurances that a 64-bit boundary is the right way to go end up sounding a bit near-sighted, and we have those TWO…

Let's not forget history. Originally IPv6 (under a different name)
was to have 64-bit fully CIDRised addresses. Let me see, that
would have allowed 16 billion billion addresses, but they would
have behaved just like IPv4 addresses.

Then there was a consensus decision to add the extra value of a
distinct interface identifier, originally expected to be 48 bits,
so we'd have had a /80 subnet prefix (fully CIDRised). That got
changed to 64 bits when Firewire (and the original 8+8 proposal)
came along, so we got a /64 subnet prefix. And at some point it
was also decided that architecturally, the whole /128 should be
CIDRised as far as routing goes. That hasn't changed and there
is no proposal to change it.

Any site that steps outside the standard by splitting a /64
into multiple prefixes is doing so at its own risk, and we need
to state that, I think. (The only exception being /127.)

   Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 07 Mar 2014 12:31:46 +0100

Le 07/03/2014 02:18, David Farmer a écrit :
>  proviso "with the expectation that the document is changed to making
> a positive statement as opposed to a defensive one."
>
> conclusion is being pushed?

I personally don't know either, frankly speaking; I discussed with some 
people that expressed the same question.

I would like that any byproduct of this should not lead to continue the 
current situation of cellular operators offering only one /64 per one 
connection.  This is less and less acceptable.

> That 64 bit IIDs are the right size.

Yes, provided that the Internet providers think about the end users who 
need several of these.  Otherwise it is not the right size.

> Or, that we should allow different IID sizes.  Or, something else.

I dont know.

> situations.  However, I'm also very suspicious of one size fits all

I agree.

> operational recommendation.

I agree in a sense, although this may consitute a break in coming up 
with IP sensors which send 2bits of data, on slow links.

> IIDs, but they SHOULD NOT be the default IID for typical Internet
> user devices, but that's a different issue and draft.
>
> the IPv6 architecture was for a variable IID size, and so IIDs
> shorter than 64 should be ensured in our IPv6 protocol designs and
> implementations. Rather that anointing 64 bit IIDs as the one true
> IID size.  I'd like to see autoconf for IIDs other that 64 bits as
> well, but that should be a longer-term change in the specs in my
> opinion.

I agree.

Alex

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 8 Mar 2014 00:29:42 -0800 (PST)

----- Original Message -----
> From: Brian E Carpenter <[email-masked]>
> To: Mark ZZZ Smith <[email-masked]>
> Cc: David Farmer <[email-masked]>; Ole Troan <[email-masked]>; 6man WG <[email-masked]>
> Sent: Friday, 7 March 2014 7:59 PM

Exactly.

I only recently came across RFC5505 ("Principles of Internet Host Configuration"), and I think it might be worth referring to that, and pointing out that having single same sized IID (and consequently same sized edge prefix length) satisfies the Minimize Configuration principle.

> the specs and results may vary.

Yes.

> the 
> boundary between the prefix and the IID is a "soft" boundary between 
> the fields, rather than a hard one. They are soft boundaries rather than hard 
> incorrect, they can be changed, without requiring an upgrade to the all of the 
> forwarding devices in the Internet. It is probably fundamentally an outcome of 
> the lessons learned from the effort involved in the change from classful to 
> classless forwarding in IPv4 in the mid 1990s.
>> 
> worth contrasting IPv6 with RFC791 classful and earlier RFC760 "single 
> class" IPv4 (with IEN115 also making the hard boundary between network and 
> 'local address' field in early IPv4 clear), and perhaps mentioning that 
> other earlier protocols have had distinct network and host/node fields in their

---

From: Matthew Petach <[email-masked]>
Date: Sun, 9 Mar 2014 11:33:28 -0700

On Thu, Mar 6, 2014 at 5:18 PM, David Farmer <[email-masked]> wrote:

>> There was consensus to adopt draft-carpenter-6man-why64 as a 6MAN working
>> group item at the IETF89 working group meeting, with the expectation that
>> the document is changed to making a positive statement as opposed to a
>> defensive one.
> [...]
> IPv6 architecture was for a variable IID size, and so IIDs shorter than 64
> should be ensured in our IPv6 protocol designs and implementations. Rather
> than anointing 64 bit IIDs as the one true IID size.  I'd like to see
> autoconf for IIDs other that 64 bits as well, but that should be a
I'm with David on this one; IPv6 should fully support VLSM, and not have
hard-coded classful boundaries embedded within it.  64 bits as a recommended
IID size, and as the default IID size is fine, but we should ensure it is
clear
that using different IID sizes is not against protocol specs, and does
constitute
a valid network design.  Noting that autoconf may not function on networks
with non-64-bit IIDs as a warning to those working with different sized
boundaries is probably good, to avoid well-meaning-but-not-entirely-clueful
operators from complaining about why their off-the-shelf CPE didn't
autoconfigure their 32-bit IID field correctly.  But it should be left as an
operational warning, rather than a protocol definition.

Matt
(and non /64 subnet masks should really *not* cause kernel
panics in operating systems...but that's a rant for a different
community.  :/ )

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Mar 2014 21:21:31 +1300

> operational warning, rather than a protocol definition.

The 64 *is* a protocol definition in the standards track documents.
(RFC 4291, updated by RFC 7136):

   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long.

The current draft is informational and can't change this. It should
certainly contain the necessary warnings.

   Brian

> ------------------------------------------------------------------------
>

---

From: Ole Troan <[email-masked]>
Date: Mon, 10 Mar 2014 14:16:05 +0100

> certainly contain the necessary warnings.

if we got the address allocation and the 64 bit boundary wrong, we have at least 5/8th of the IPv6 address space to try something different.

cheers,
Ole

---

From: David Farmer <[email-masked]>
Date: Tue, 11 Mar 2014 14:39:18 -0500

> not the proposal put to a hum this week.

I guess I'm OK with that as far as it goes.

However, if we agree that the IPv6 architecture is designed to be VLSM; 
combined with the fact that ND has a prefix length field; then while 
IIDs are currently specified to only be 64 bits, it seems implicit that 
other IID lengths are anticipated by the architecture.

Therefore, unless the conclusion proposed is that there should never be 
IIDs other than 64 bits, which I believe would also be beyond the scope 
of an informational RFC as well, I would like to suggest we consider the 
conclusion of the draft as a problem statement in that most 
implementations seem to ignore any IIDs other than 64 and this will be a 
serious forward compatibility issue if other IID lengths are ever 
specified in the future.

I would like to suggest, maybe just to illustrate the issue I'm 
concerned about, that implementations MAY by default ignore the prefix 
lengths other than 64, if only if they have a configurable option to 
obey prefix lengths other than 64.  Unless, I'm misunderstanding the 
data in section 5.1.

While thinking about this, there is an argument that IIDs of length 1 
(or prefix length /127) is valid because of RFC6164, even discussed in 
the draft, and maybe allowing the two routers to auto-discover addresses 
from each other would be useful. Just an idea to throw out and maybe 
part of the potential problem statement for the conclusion.

Thanks

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Mar 2014 20:54:19 +1300

> serious forward compatibility issue if other IID lengths are ever

Actually I'm not sure we know that, without code inspections. Certainly
a conforming implementation of an IPv6-over-foo that specifies a 64 bit
IID for foo links will only support 64. But in a well designed stack,
the IP layer itself will treat that 64 as a parameter, so it's only
the IPv6-over-foo code that needs to be updated.

> obey prefix lengths other than 64.  Unless, I'm misunderstanding the

Well, we should re-empahsise that the IID length should be a parameter
in all code where that is meaningful.

> part of the potential problem statement for the conclusion.

I think the issue is that today we assume that all nodes on a given
link know the IID length in advance. Otherwise link-local addresses can't
be formed consistently.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 12 Mar 2014 20:23:33 +0900

On Wed, Mar 12, 2014 at 4:39 AM, David Farmer <[email-masked]> wrote:

> combined with the fact that ND has a prefix length field; then while IIDs
> are currently specified to only be 64 bits, it seems implicit that other
> IID lengths are anticipated by the architecture.
>
> IIDs other than 64 bits, which I believe would also be beyond the scope of
> an informational RFC as well, I would like to suggest we consider the
> conclusion of the draft as a problem statement in that most implementations
> seem to ignore any IIDs other than 64 and this will be a serious forward
> compatibility issue if other IID lengths are ever specified in the future
>

Well, but people might not agree that that's a problem. For example, I
happen to think it's acceptable and perhaps even desirable to not allow
IPv6 addresses to have prefix lengths between /65 and /126.

If others agree with me, then it's possible we won't be able to get
consensus on that problem statement, and therefore we should just maintain
the current content of this draft as "this is the current state of affairs,
and here's why it was designed this way".

Note: I happen to think that there are good reasons for this split, and I
would love to see the draft say "we believe /64 is the right way to go
because...", but realistically, I'm not sure such a statement would gain
consensus either :-)

---

From: [email-masked]
Date: Wed, 12 Mar 2014 12:41:41 +0100 (CET)

> IPv6 addresses to have prefix lengths between /65 and /126.

I happen to think it's completely unacceptable - and would consider
such equipment ineligible for purchase. Fortunately, none of the
big name equipment vendors that I know about have implemented such a
restriction.

An example showing that I'm not *totally* alone here is that at least
one of our big name transit providers use /126 for IPv6 link addresses.

Steinar Haug, AS 2116

---

From: Jen Linkova <[email-masked]>
Date: Wed, 12 Mar 2014 14:02:30 +0100

> one of our big name transit providers use /126 for IPv6 link addresses.

I wonder if there are any reasons for using /126 besides 'we used to
use /30 in IPv4 (because /31 did not work well on some equipment) so
let's do the same for IPv6'.

-- 
SY, Jen Linkova aka Furry

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 12 Mar 2014 13:16:51 +0000

> I felt the urge to support this text. I think Mark has stated this very well. The assurances that a 64-bit boundary is the right way to go end up sounding a bit near-sighted, and we have those TWO…

On that point I would agree. I would actually take it a step further; /64 is a convention required by SLAAC and ILNP, and irrelevant if addresses are handled in other ways. To the host, apart from ILNP, the address is a 128 bit number.

---

From: Tore Anderson <[email-masked]>
Date: Wed, 12 Mar 2014 19:28:43 +0100

Hi Jen,

> let's do the same for IPv6'.

If you want customers that are running some flavour of Linux predating
RFC 6164 on their CE you can't use /127s.

Tore

---

From: Steven Blake <[email-masked]>
Date: Wed, 12 Mar 2014 16:52:19 -0400

> one of our big name transit providers use /126 for IPv6 link addresses.

One very well know silicon vendor who has sold lots of chips used in
deployed equipment from major vendors allocates 32x more on-chip FIB
entries for prefixes <= /64 vs. prefixes between /65 and /128.

Significant savings in memory/power/lookup latency can be achieved if HW
engineers are allowed to assume that only a handful of prefixes are
> /64.

Regards,

// Steve

---

From: [email-masked]
Date: Wed, 12 Mar 2014 22:21:31 +0100 (CET)

> engineers are allowed to assume that only a handful of prefixes are

I don't really have a problem with that, as long as it's possible
to use them. I *do* have a problem with trying to prohibit specific
prefix lengths > 64.

Steinar Haug, AS 2116

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Mar 2014 14:41:40 -0700

> the IPv6-over-foo code that needs to be updated.

  Brian,

I agree that would be a sensible way to implement things. I don't know
whether this is how things have been implemented though. I hope that the
000 exception to 64 bit IIDs means that generic IPv6 code doesn't assume
64 bits.

> in all code where that is meaningful.

  I also think we should request that IETF standards work not assume that
the IID length is of a particular value.
Having some specific protocols (such as IPv6 over Ethernet combined with
SLAAC, or CGA) work only for 64 bit IIDs

> link know the IID length in advance. Otherwise link-local addresses can't

  The link-local prefix is fe80::/10 [RFC4291] hence there is plenty of
room to have different IID length and use them to form link-locals.
We don't have any ip-over-foo documents with anything but 64 bit IIDs. I
don't think RFC 6164 claims that the last bit is an IID but just says
that the prefix is 127 bits.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Mar 2014 14:43:01 -0700

> to use them. I *do* have a problem with trying to prohibit specific

+1

Also, unless we are going to remove the 000 exception from the 
addressing architecture, we can't completely prohibit particular prefix 
lengths.

    Erik

---

From: Ole Troan <[email-masked]>
Date: Wed, 12 Mar 2014 23:06:24 +0100

> to use them. I *do* have a problem with trying to prohibit specific

Deering said the following in 2002, when there is a thread with the same discussion as we're having now:

"When I get asked about what assumptions can be made about unicast prefix
lengths (e.g., by people designing route look-up implementations), I
tell them that they should be prepared to handle any prefix length,
but that it will probably be OK if prefixes between 65 and 127, inclusive,
are handled in a slower path (i.e., if you can't build the fully-general
mechanism at an acceptable cost, you probably won't get burned if you
optimize for prefixes between 0 and 64, plus 128 (for "host routes"))."

the 64 bit boundary is there largely by decree (i.e. a policy), although Brian's draft shows it being embedded in specifications by now. policy can change, and as there are exceptions, it would be a far stretch to conclude that one should based on the IPv6 addressing architecture build forwarding engines that can only handle prefix lengths of <=/64 and /128.

cheers,
Ole

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Mar 2014 14:08:55 -0700

Brian,

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Mar 2014 14:42:52 -0700

+1

    Erik

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 13 Mar 2014 15:39:35 +0900

> one of our big name transit providers use /126 for IPv6 link addresses.

If it's the provider I think you mean, then they did it because their
equipment did not support /127.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 13 Mar 2014 15:41:30 +0900

> to use them. I *do* have a problem with trying to prohibit specific

Oh, you *can* use them. You just can't use very many of them, because they
get deaggregated into /128 matches :-D

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Mar 2014 22:50:59 +1300

On 13/03/2014 04:13, 神明達哉 wrote:
> At Wed, 12 Mar 2014 20:54:19 +1300,
> Brian E Carpenter <[email-masked]> wrote:
> 
> Right, and that's why I tried to say in my previous message.  BSD
> variants implement it this way:
> 
>         /*
>          * Prefix Length check:
>          * If the sum of the prefix length and interface identifier
>          * length does not equal 128 bits, the Prefix Information
>          * option MUST be ignored.  The length of the interface
>          * identifier is defined in a separate link-type specific
>          * document.
>          */
>         ifidlen = in6_if2idlen(ifp);
> [...]
>         if (ifidlen + pr->ndpr_plen != 128) {
>             nd6log((LOG_INFO,
>                 "prelist_update: invalid prefixlen "
>                 "%d for %s, ignored\n",
>                 pr->ndpr_plen, if_name(ifp)));
>             goto end;
>         }
> (see lines 1228-1241 of
> https://github.com/freebsd/freebsd/blob/master/sys/netinet6/nd6_rtr.c)
> 
> And, under the currently published IPv6-over-foo RFCs, in6_if2idlen()
> always returns 64 for all known types of interfaces (IPv6-over-foo
> docs are super clear on this point; how could it be implemented
> differently?), which is why the BSD implementations behave as
> described Section 5.1 of 6man-why64-01.
> 
> But the description of 6man-why64-01 could read as if it's implemented
> as follows:
> 
>         if (pr->ndpr_plen != 64) {
>             nd6log((LOG_INFO,
>                 "prelist_update: invalid prefixlen "
>                 "%d for %s, ignored\n",
>                 pr->ndpr_plen, if_name(ifp)));
>             goto end;
>         }
> 
> and is misleading.  I also see the same confusion in this particular
> email thread.  I understand these two cannot be distinguishable from
> an external observer, but IMO the draft text should be revised to
> avoid this type of misunderstanding.

I completely agree.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Mar 2014 23:24:12 +1300

Erik,

On 13/03/2014 10:08, Erik Nordmark wrote:
...
> room to have different IID length and use them to form link-locals.

Right, but surely something may go wrong if different hosts on
the same link assume different IID lengths for LL? What happens if
a host decides to use 118 pseudo-random bits, but other hosts
are using 64 bits?

If that will "just work" with SLAAC, it does need a minor change in
the draft.

> that the prefix is 127 bits.

Sure, but we aren't expecting SLAAC to work on such a link.

   Brian

---

From: David Farmer <[email-masked]>
Date: Thu, 13 Mar 2014 09:15:25 -0500

On 3/12/14, 06:23 , Lorenzo Colitti wrote:
> On Wed, Mar 12, 2014 at 4:39 AM, David Farmer <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     However, if we agree that the IPv6 architecture is designed to be
>     VLSM; combined with the fact that ND has a prefix length field; then
>     while IIDs are currently specified to only be 64 bits, it seems
>     implicit that other IID lengths are anticipated by the architecture.
>
>     Therefore, unless the conclusion proposed is that there should never
>     be IIDs other than 64 bits, which I believe would also be beyond the
>     scope of an informational RFC as well, I would like to suggest we
>     consider the conclusion of the draft as a problem statement in that
>     most implementations seem to ignore any IIDs other than 64 and this
>     will be a serious forward compatibility issue if other IID lengths
>     are ever specified in the future
>
>
> consensus on that problem statement, and therefore we should just
> maintain the current content of this draft as "this is the current state
> of affairs, and here's why it was designed this way".
>
> Note: I happen to think that there are good reasons for this split, and
> I would love to see the draft say "we believe /64 is the right way to go

Operationally I believe /64 is the way to go.  But there are both 
operational and architectural issues to be considered as part of the 
discussion.

I would be fine with a very strong operational statement that /64 is the 
way to go, along with /127 and /128 for their special cases of 
point-to-point links and loop-backs.  But we need to explain why, and it 
will have much more effect if the explanation is more than the moral 
equivalent of "because I said so".

However, the demand for IIDs with prefix lengths between /65 and /126 by 
some operators is evidence that the arguments either are not convincing 
or are misunderstood, or that we are not listening to issues and 
problems of these operators.  In my opinion, these are the things  that 
this draft should address, either by providing clear and convincing 
arguments and/or by investigate the problem space.

While prefix lengths between /65 and /126 are currently operationally 
invalid, not currently specified, they are architecturally valid.  So, 
it needs to be reinforce that VLSM and a variable a length IID are 
fundamental to the IPv6 architecture, and all IPv6 stacks must be able 
to deal with these prefix lengths if/when they are specified as 
operationally valid.  If this weren't the case then it would have been 
operationally impossible to implement RFC6164 without major stack rewrites.

I think it is imperative to insure IPv6's longevity by protecting the 
ability to change the valid IID sizes without major stack rewrites.  I'd 
even prefer some minimal forward compatibility of all current stacks.  I 
believe this view is fully compatible with the current standards track 
documents.

Thanks

---

From: David Farmer <[email-masked]>
Date: Thu, 13 Mar 2014 09:23:28 -0500

On 3/13/14, 01:41 , Lorenzo Colitti wrote:
> On Thu, Mar 13, 2014 at 6:21 AM, <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Oh, you *can* use them. You just can't use very many of them, because
> they get deaggregated into /128 matches :-D

The discussion of these limitations in routing implementations needs 
more details, this is the kind of thing that puts meat on the argument 
and makes the argument more than "because I said so".

Please help Brian by providing more details on this issue to go in the 
draft.

---

From: Steven Blake <[email-masked]>
Date: Thu, 13 Mar 2014 13:57:35 -0400

> to use them. I *do* have a problem with trying to prohibit specific

Use a handful of them (/65 - /128), or an arbitrarily large fraction of
your total prefixes?  The former can be accommodated fairly cheaply; the
latter impacts total cost/power/performance.  Specifically, as a
dataplane designer I have to budget for more FIB memory and lookup
cycles or wider TCAM entries or more on-chip table memory (which might
not be efficiently used for <= /64 prefixes).

Regards,

// Steve

---

From: Steven Blake <[email-masked]>
Date: Thu, 13 Mar 2014 14:03:02 -0400

> optimize for prefixes between 0 and 64, plus 128 (for "host routes"))."

That advice doesn't make a lot of sense: in the general case you cannot
know whether an address matches a longer prefix without attempting the
lookup.

> the 64 bit boundary is there largely by decree (i.e. a policy),
> although Brian's draft shows it being embedded in specifications by
> now. policy can change, and as there are exceptions, it would be a far
> stretch to conclude that one should based on the IPv6 addressing
> architecture build forwarding engines that can only handle prefix 
> lengths of <=/64 and /128.

I am not aware of HW that totally precludes prefixes > /64.  I am aware
of HW that is highly optimized for prefixes /0 - /64 + /128.

Regards,

// Steve

---

From: Steven Blake <[email-masked]>
Date: Thu, 13 Mar 2014 14:17:52 -0400

> Please help Brian by providing more details on this issue to go in the 

Without violating NDAs, I can say with confidence that there are
billions of dollars worth of deployed campus/enterprise/datacenter
Ethernet gear that can only support a handful of /64 - /127 prefixes in
dataplane HW.

Regards,

// Steve

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 13 Mar 2014 11:33:53 -0700

> If that will "just work" with SLAAC, it does need a minor change in
Brian,
this might be an area where the RFCs are not sufficiently clear to 
result in implementations which would allow all of fe80::/10 to be used 
with with non-zero bits from 10-64. I think at least early Kame code was 
using those bits locally within the software to store the interface 
index or something like that. And I don't think there are IPv6 tests 
which verify that implementations treat fe80::/10 as on-link - there are 
probably implementations which only treat fe80::/64 as on-link.

My point is that from an addressing architecture perspective the 
link-local definition is not a constraint.
Thus if ever there is a new ip-over-foo which would like to use say 70 
bit IIDs, link-local addresses can be formed using such IIDs. The 
implementations which support that new hypothetical ip-over-foo might 
need to tweak their generic IPv6 code.
(Such an ip-over-foo would need to operate in the 0::/3 range of global 
addresses to be consistent with RFC 4291 though.)

> Sure, but we aren't expecting SLAAC to work on such a link.
RFC 4862 would work fine on the above hypothetical 70 bit IID 
ip-over-foo; the RA PIO would need to have a 58-bit prefix for this.
(Hence also restricted to 0::/3 part of the address space.)

Thus this is rather academic. But we should try to not make statements 
in future RFCs which are inconsistent with RFC 4291 and RFC 4862.

Regards,
    Erik

---

From: Tim Chown <[email-masked]>
Date: Thu, 13 Mar 2014 19:22:16 +0000

On 13 Mar 2014, at 14:15, David Farmer <[email-masked]> wrote:

> However, the demand for IIDs with prefix lengths between /65 and /126 by some operators is evidence that the arguments either are not convincing or are misunderstood, or that we are not listening to issues and problems of these operators.  In my opinion, these are the things  that this draft should address, either by providing clear and convincing arguments and/or by investigate the problem space.

So who are these operators?

Tim

---

From: [email-masked]
Date: Thu, 13 Mar 2014 20:43:52 +0100 (CET)

> your total prefixes?

Probably more than a handful (more like a few hundred) but certainly
not an arbitrarily large fraction of total prefixes.

Steinar Haug, AS 2116

---

From: Brian Jones <[email-masked]>
Date: Thu, 13 Mar 2014 10:06:27 -0400

​I'm against​
 prohibit
​ing​
the use of specific prefix lengths
​ > 64 also.

Brian Jones, AS 1312​
​

---

From: manning bill <[email-masked]>
Date: Thu, 13 Mar 2014 18:26:13 -0700

if one reviews the design discussions, there were reasons to go beyond /64
and it would be foolhardy to second guess/limit future options by cutting the address space 
back to only 64 bits.   (My home network has been addressed out of a single /112 for 15 years)

/bill
Neca eos omnes.  Deus suos agnoscet.

On 13March2014Thursday, at 7:06, Brian Jones <[email-masked]> wrote:

> 
> ​I'm against​ prohibit​ing​ the use of specific prefix lengths ​ > 64 also.
> 
> 
> Brian Jones, AS 1312​​
>

---

From: [email-masked]
Date: Fri, 14 Mar 2014 06:39:42 +0100 (CET)

> back to only 64 bits.   (My home network has been addressed out of a single /112 for 15 years)

For another example of the use of /112, see

https://www.nanog.org/meetings/nanog48/presentations/Tuesday/Loch_LinkNumb_N48.pdf

Steinar Haug, AS 2116

---

From: [email-masked]
Date: Fri, 14 Mar 2014 09:57:54 +0100 (CET)

> https://www.nanog.org/meetings/nanog48/presentations/Tuesday/Loch_LinkNumb_N48.pdf

For yet another example, see

http://www.ripe.net/lir-services/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf

Section 4.12 p. 18, "Addressing point-to-point links":

- /112 makes it possible to avoid reserved anycast addresses and has
the advantage that the entire four-digit hex value after the last
colon in the IPv6 address identifies systems within the subnet.

Steinar Haug, AS 2116

---

From: <[email-masked]>
Date: Fri, 14 Mar 2014 10:44:37 +0100

Dear all,

I'm not sure what is the positive statement to be included in the document. But, I would be fine with a conclusion reflecting the following points:

* forwarding and routing processes must not make any assumption on the maximum length of the prefixes.
* prefixes assigned to end sites must preserve the 64bits boundary. This is, in particular, to be compatible with existing autoconf procedures and also to offer locator/identifier separation a la ILNP as recommended by RRG.

Cheers,
Med

>-----Message d'origine-----
>De : ipv6 [mailto:[email-masked]] De la part de Ole Troan
>Envoyé : mercredi 5 mars 2014 11:20
>À : 6man WG
>Objet : Subject: Confirming consensus on adopting draft-carpenter-6man-
>why64
>
>There was consensus to adopt ￼￼draft-carpenter-6man-why64 as a 6MAN working

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 14 Mar 2014 18:49:14 +0900

On Fri, Mar 14, 2014 at 6:44 PM, <[email-masked]> wrote:

> I'm not sure what is the positive statement to be included in the
> document. But, I would be fine with a conclusion reflecting the following
> points:
>
> * prefixes assigned to end sites must preserve the 64bits boundary. This
> is, in particular, to be compatible with existing autoconf procedures and
> also to offer locator/identifier separation a la ILNP as recommended by RRG.
>

I don't think this document can say MUST anything, since its intended
status is informational.

---

From: Ole Troan <[email-masked]>
Date: Fri, 14 Mar 2014 10:59:20 +0100

Med,

<nohat>

> * prefixes assigned to end sites must preserve the 64bits boundary. This is, in particular, to be compatible with existing autoconf procedures and also to offer locator/identifier separation a la I…

this is a informational document, I would prefer there wasn't any RFC2119 language in it.

I was more thinking of something giving the benefits of the /64:

- let us recognise that there is a "tussle" between hosts and the network, and the ISP and the end-user. the /64 boundary draws a line in the sand, the first 64 bits are controlled by the network, the last 64 bits by the hosts

- the /64 boundary allows lots of new innovation. CGA, privacy addresses, identifier / locator split with ILNP...

- it makes subnetting in IPv6 much simpler than in IPv4. all subnets are /64. no longer any need to play around with the subnet calculator and remember that there are 6 hosts in a 255.255.255.248. an IPv6 addressing plan enumerate subnets, not hosts.
from operator perspective it is very simple to see the "network" part of the address

I'm sure there are several more.

cheers,
Ole

---

From: <[email-masked]>
Date: Fri, 14 Mar 2014 11:03:27 +0100

Re-,

The discussion is not on the normative language but what to put in the document so that it can be useful. IMHO I see this document as a way to educate, explain design motivations, and call out (including recall) guidelines/recommendations to be followed.

The document is completely useless if clear guidelines are not sketched.

IMO, it is fundamental to not link routing/forwarding to the prefix/address semantic.

Cheers,
Med

De : Lorenzo Colitti [mailto:[email-masked]]
Envoyé : vendredi 14 mars 2014 10:49
À : BOUCADAIR Mohamed IMT/OLN
Cc : Ole Troan; 6man WG
Objet : Re: Subject: Confirming consensus on adopting draft-carpenter-6man-why64

On Fri, Mar 14, 2014 at 6:44 PM, <[email-masked]<mailto:[email-masked]>> wrote:
I'm not sure what is the positive statement to be included in the document. But, I would be fine with a conclusion reflecting the following points:

I don't think this document can say MUST anything, since its intended status is informational.

---

From: <[email-masked]>
Date: Fri, 14 Mar 2014 11:18:22 +0100

Hi Ole,

Design principles documents (e.g., rfc1958 or rfc3439) uses "must" wording even if these documents are informational. 

This one is really useful if clear guidelines are included. 

Cheers,
Med

>De : Ole Troan [mailto:[email-masked]]
>Envoyé : vendredi 14 mars 2014 10:59
>Cc : 6man WG
>- let us recognise that there is a "tussle" between hosts and the network,
>and the ISP and the end-user. the /64 boundary draws a line in the sand,
>the first 64 bits are controlled by the network, the last 64 bits by the
>hosts
>
>- it makes subnetting in IPv6 much simpler than in IPv4. all subnets are
>/64. no longer any need to play around with the subnet calculator and
>remember that there are 6 hosts in a 255.255.255.248. an IPv6 addressing
>plan enumerate subnets, not hosts.

---

From: Tim Chown <[email-masked]>
Date: Fri, 14 Mar 2014 10:35:31 +0000

Hi Ole,

> I'm sure there are several more.

So there isn’t currently an “advantages to having a consistent /64 prefix length” section.  We could add that.  Currently ithe document cites examples of where /64 is not used, and the potential pitfalls you may encounter if doing so.

There are two scenarios we could consider breaking out, i.e. end host links, and those which are p2p router links.

I don’t believe the document should carry any MUSTs either.

Tim

---

From: Fernando Gont <[email-masked]>
Date: Fri, 14 Mar 2014 09:18:14 -0300

Hi, Erik,

> SLAAC, or CGA) work only for 64 bit IIDs

FWIW, in draft-ietf-6man-stable-privacy-addressess we included some text
such that *this* I-D itself is not tied to 64 bits (something along the
lines of "take as many bits as necessary to form an IID...Currently 64
bits, but this woul work for other IID lengths too").

> room to have different IID length and use them to form link-locals.

I seem to recall some RFC (4291?) that, when illustrating the syntax of
link-locals, they seem to require fe80::/64...

FWIW, in practice link-locals need to be fe80::/64, since BSDs store the
interface index (and some other stuff, IIRC) in the assumed-to-be-zero
bits in the fe80::/64 prefix.

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

---

From: 神明達哉 <[email-masked]>
Date: Fri, 14 Mar 2014 10:22:49 -0700

At Fri, 14 Mar 2014 09:18:14 -0300,

> link-locals, they seem to require fe80::/64...

Yes (sort of), in Section 2.5.6 of RFC 4291.  "sort of" because this
section actually doesn't say about a prefix; it only talks about the
"format":

   Link-Local addresses are for use on a single link.  Link-Local
   addresses have the following format:

   |   10     |
   |  bits    |         54 bits         |          64 bits           |
   +----------+-------------------------+----------------------------+
   |1111111010|           0             |       interface ID         |
   +----------+-------------------------+----------------------------+

Since the intermediate 54 bits are required to be 0, it happens to be
represented as fe80::/64, but I can imagine these bits could have been
just "reserved".

On a related point, another thing that could cause confusion for
unicast link-local addresses is that Section 2.4 of the same RFC
mentions the prefix of fe80::/10:

   The type of an IPv6 address is identified by the high-order bits of
   the address, as follows:

      Address type         Binary prefix        IPv6 notation   Section
      ------------         -------------        -------------   -------
[...]
      Link-Local unicast   1111111010           FE80::/10       2.5.6

I'm not sure if it has to be in 6man-why64, but it would be nice if we
can clarify the (seeming) gap between these two, somewhere.

> bits in the fe80::/64 prefix.

As far as I know BSDs still do this trick, but to be very accurate, if
only for this reason it does not necessarily have to be /64, since the
implementation only uses the 2nd 16 bits for this purpose.  So, in
theory, it could still work for any prefix equal to or longer than /32
(though the actual BSDs implementation still assumes /64).

--
JINMEI, Tatuya

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 14 Mar 2014 10:37:32 -0700

> section actually doesn't say about a prefix; it only talks about the
Jinmei,

Good catch.
>     |  bits    |         54 bits         |          64 bits           |
I remember that the fe80::/64 vs. fe80::/10 came up on the list a number 
of years back, but I don't know if that resulted in any (suggested) 
clarifications. Does anybody remember?

My take is that the figure in 2.5.6 shows how addresses are intended to 
be allocated. But the definition for "link-local address" is anything 
covered by fe80::/10.
For example, I would assume that
    Routers must not forward any packets with Link-Local source or
    destination addresses to other links.
should apply to fe80::/10.

But I don't know what existing implementations do.

Nor is it clear to be that any clarification for link-locals belong in 
why64.
Regards,
    Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Mar 2014 09:42:03 +1300

Med,

The language on this point in the addressing architecture is
(IMHO) unambiguous and of course authoritative, so my editing
pen won't be putting pseudo-normative text in an informational
document.

As far as I can see, this thread is no longer helping to clarify
the text in the draft, which as we emphasised in London does not
propose any change to the specifications. What it will do, as
requested in the meeting, is to underline *why* the WG still thinks
that a uniform IID length is a good idea.

Yes, I know that a few people disagree.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Mar 2014 09:49:31 +1300

below...

> Nor is it clear to be that any clarification for link-locals belong in

Well, noting that the LL IIDs are clearly defined to be exactly 64 bits
is worthwhile, I think. The 54 bits that must be zero aren't
directly relevant.

     Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 14 Mar 2014 20:50:06 +0000

> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter

> Yes, I know that a few people disagree.

FWIW, I'm not disagreeing that there's a lot to be said for a fixed length IID (although some of the DOS attack excuses can be argued both ways). Just saying that this discussion of "why 64 bit IID" should not expand into a blanket restriction on wider prefixes in the future. I was starting to get that message.

Bert

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Mar 2014 23:05:09 +0100

Le 14/03/2014 10:44, [email-masked] a écrit :
> document. But, I would be fine with a conclusion reflecting the
> following points:
>
> * prefixes assigned to end sites must preserve the 64bits boundary.
> This is, in particular, to be compatible with existing autoconf
> procedures and also to offer locator/identifier separation a la ILNP
> as recommended by RRG.

I am not sure whether these recommendatins - however valid they may
sound in the statements of many/majoirty(?) - should go in this why64
draft.  Maybe better in a separate document.  I am finding recommending 
valuable, but the why64 doc just tries to say why 64.

That aside, I would like to comment on your statement on preserving the
64bit boundary.

This point creates some conflict between one particular operator
offering access, and one particular user using this access.

I think the operator believes that 64 limit is important because it is
standardized and because the manufacturer enforces it.  A side effect of
the situation is that operator believes that if it gives a 64 to an end
user then only one end user is there, not several (so only one bill).
But the first 2 are false, and thus the conclusion is so too.

For the standards: the current IETF and 3GPP standards do not require
the 64 limit; the newest 4G links use IEEE MAC addresses but they dont
run IEEE protocols.  The 000 prefixed IPv6 addresses can be
other-than-64 IIDs.

For the manufacturers: it is easy to change implementation anf go beyond
that 64 limit.

An IPv6-over-4G document which states that the IID for a 4G link is
47bit, and another IPv6-over-WiFi which states that the IID is 48bit
wouldnt hurt anyone, I think.  This would allow to have mobile hotspots
with SLAAC (not DHCP, not NAT, no PD, no 64share).

Given that, the operator will have less confidence that there is only
one user behind a 64, and will have to use some other mechanism to
ensure the number of users are billed appropriately.

Alex

>
> Cheers, Med
>
>> -----Message d'origine----- De : ipv6
>> [mailto:[email-masked]] De la part de Ole Troan Envoyé :
>> mercredi 5 mars 2014 11:20 À : 6man WG Objet : Subject: Confirming
>> consensus on adopting draft-carpenter-6man- why64
>>
>> There was consensus to adopt ￼￼draft-carpenter-6man-why64 as a
>> 6MAN working group item at the IETF89 working group meeting, with
>> the expectation that the document is changed to making a positive
>> Best regards, Ole and Bob
>  IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Mar 2014 23:05:50 +0100

Le 14/03/2014 11:03, [email-masked] a écrit :
> Re-,
>
> The discussion is not on the normative language but what to put in the
> document so that it can be useful. IMHO I see this document as a way to
> educate, explain design motivations, and call out (including recall)
> guidelines/recommendations to be followed.
>

I agree - good not to link these two.

Alex

>
> Cheers,
>
> Med
>
> *De :*Lorenzo Colitti [mailto:[email-masked]]
> *Envoyé :* vendredi 14 mars 2014 10:49
> *À :* BOUCADAIR Mohamed IMT/OLN
> *Cc :* Ole Troan; 6man WG
> *Objet :* Re: Subject: Confirming consensus on adopting
> draft-carpenter-6man-why64
>
> On Fri, Mar 14, 2014 at 6:44 PM, <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> is, in particular, to be compatible with existing autoconf procedures
> and also to offer locator/identifier separation a la ILNP as recommended
> by RRG.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Mar 2014 23:11:53 +0100

I agree.

Let me ask this: is fe80:1::1 a link-local address?

By one RFC it is, by another RFC it is not.

Alex

---

From: <[email-masked]>
Date: Mon, 17 Mar 2014 09:37:43 +0100

Hi Brian,

I suspect you are referring to the 64bits boundary, but are you sure things are clear for not linking routing & forwarding to the address semantic? Is there a clear statement somewhere saying that routing & forwarding processes must not make any assumption on the prefix length?

I still think the document is really useful if it draws (including recall) clear design principles covering this technical points. 

Cheers,
Med

>De : Brian E Carpenter [mailto:[email-masked]]
>Envoyé : vendredi 14 mars 2014 21:42
>> Design principles documents (e.g., rfc1958 or rfc3439) uses "must"
>wording even if these documents are informational.
>>
>>> Objet : Re: Subject: Confirming consensus on adopting draft-carpenter-
>6man-
>>> why64
>>>
>>> Med,
>>>
>>> <nohat>
>>>
>following
>This
>and
>>> this is a informational document, I would prefer there wasn't any
>RFC2119
>>> language in it.
>>>
>>> - the /64 boundary allows lots of new innovation. CGA, privacy
>addresses,
>>> identifier / locator split with ILNP...
>>>

---

From: 神明達哉 <[email-masked]>
Date: Mon, 17 Mar 2014 09:20:09 -0700

At Fri, 14 Mar 2014 10:37:32 -0700,

> clarifications. Does anybody remember?

(I don't)

> should apply to fe80::/10.

I think my understanding is compatible with yours:
- a node must recognize any fe80::/10 addresses as unicast link-local
  addresses
- if a node configures a unicast link-local address, it must match
  fe80::/64

But this would trigger some subtle corner cases:

- what should a node do if it's asked to send a packet to fe80:1::1,
  fe80:0:1::1, etc (with specifying the outgoing link)?
- what should a node do if it receives a packet from fe80:1::1,
  fe80:0:1::1, etc?

An implementation wouldn't be called "non compliant" even if it makes
the first case fail and rejects the second case.  But in the spirit of
"be liberal in what you accept" (maybe a naive concept in the 21st
century), this might be considered too restrictive.  It may not be so
unrealistic that a future extension uses the intermediate 54 bits for
some purposes.

> Nor is it clear to be that any clarification for link-locals belong in

The specific issue of fe80::/10 vs fe80::/64 is probably out of scope
of why64.  But if many of us think it's worth clarifying or at least
worth identifying what's possible unclear I'm happy to volunteer to
write a short separate draft for it.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Mar 2014 06:17:14 +1300

Dear 6man chairs,

Can you let the authors know whether you consider that there's rough
consensus to adopt the draft (modified according to the comments made
in London and on the list)?

Regards
   Brian

---

From: Ole Troan <[email-masked]>
Date: Tue, 25 Mar 2014 21:35:58 +0100

The chairs believe there is a consensus to adopt this document as an working group document in 6MAN that is intended to be an Informational RFC.

The chairs would emphasize that this document will not change the /64 boundary.  Doing so would be very disruptive to the current IPv6 deployment efforts.  Further, a change of this scope does not appear to be consistent with the charter of the working group.

Authors, please publish the next revision as draft-ietf-6man-why64-00

Best regards,
Bob & Ole

---

From: Nabil Benamar <[email-masked]>
Date: Wed, 26 Mar 2014 09:00:48 +0000

Hi All,

It is really interesting to see that this draft is being adopted as a wg
item and that the current document will not change the /64 boundary but
could open more discussions about this fixed limit in the upcoming days.

best

*Best wishes*
*نبيل بنعمرو*
*Nabil Benamar*
*Moulay Ismail University.*
*Meknes. Morocco*
*nabilbenamar.com <http://nabilbenamar.com>*

On Tue, Mar 25, 2014 at 8:35 PM, Ole Troan <[email-masked]> wrote:

> The chairs believe there is a consensus to adopt this document as an
> working group document in 6MAN that is intended to be an Informational RFC.
>
> The chairs would emphasize that this document will not change the /64
> boundary.  Doing so would be very disruptive to the current IPv6 deployment
> efforts.  Further, a change of this scope does not appear to be consistent
> with the charter of the working group.
>