Subject: A Plea for Architectural & Specification Stability with IPv6

From: RJ Atkinson <[email-masked]>
Date: Thu, 13 Mar 2014 08:49:35 -0400

All,

  When I talk with users (academic, business/enterprise, or
governmental) about IPv6, the single most common concern they
raise is that:

	The IETF keeps changing IPv6.  Clearly IPv6 is not yet
	ready for widespread use until they stop changing 
	the specifications.

  The IETF community is largely one of protocol-minded folks.
As engineers and scientists, we also love to optimise and improve 
things.  There are daily temptations to tweak, edit, change,
and improve IETF protocols -- especially if there is an active
IETF Working Group for a given IETF protocol.

  If folks in the IETF IPv6 WG want IPv6 to be more widely deployed, 
more rapidly deployed, and its capabilities to be more widely used, 
then WE NEED TO STOP CHANGING THE IPv6 SPECIFICATIONS.

  As I say this, I specifically am NOT referring to Fernando Gont's
work, which is important in educating implementers and users about
how to safely implement, deploy, and use IPv6.  I also am NOT referring
to the work in draft-halpern-6man-nd-pre-resolve-addr, since that
I-D can be implemented and used WITHOUT any IPv6 specification 
changes.  I also am NOT referring to potential link-specific
"IPv6 over new-link-type-X" specifications that do NOT change
any of the IPv6 base specifications.

  I AM including a number of other proposals [examples include,
but are not limited to (1) changing every ND implementation merely
to optimise for one broken MAC protocol, (2) changing the IPv6 
architecture that separates IIDs from routing goop in a clean way 
with a change that (a) also reduces the entropy available from the 
IPv6 Privacy extensions, (b) facilitates tracking of users, (c) breaks 
the ability to use CGAs, and (d) breaks the ability to protect ND], 
that were presented last week and that have been topics of discussion 
on this list within the last few weeks.

  My bottom line is that non-security-related changes to the IPv6
standards-track specifications (including ND, ICMPv6, and so forth) 
needs to be avoided.

  By contrast, documenting *optional* implementation optimisations, 
ideally as Informational status documents, is fine.  Documenting security 
issues and ways that those issues can be mitigated also is fine.
Documenting how IPv6 runs over some new type of link layer also is
fine, but again really might be published as Informational status,
rather than standards-track.

Yours,

Ran Atkinson

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 13 Mar 2014 23:27:52 +0900

> then WE NEED TO STOP CHANGING THE IPv6 SPECIFICATIONS.

Hear, hear.

For a long time I've believed that int the IETF we think that IPv6 is "not
being deployed" because something is wrong with it. And so we keep changing
it. But that's not the problem. IPv6 *is* being deployed, it will just take
time. At current S-curve growth, we'll be done in 10 years.

The original IPv6 architecture is sound, and the core protocols are
perfectly deployable. They are a solid (though admittedly minor)
improvement over IPv4. There is *nothing wrong* with the IPv6 architecture.
Deploying IPv6 *as it is today* will, after a minor speed bump, lead to
simplification, cost reduction, and increased transparency of a network
that today is cluttered with brittle and expensive middleboxes (expensive
both because they cost money and because they cost developer time for apps
to work around).

It's true that those that want IPv6 to be exactly like IPv4 are
disappointed, because IPv6 is not IPv4. No, you can't do routing without
RAs. No, you can't "save addresses" by making host subnets /120s (at least
not easily). No, there is no RFC1918. No, ULAs are not the same as RFC1918.
No, there is no NAT. But I think that in a lot of scenarios those are
advantages, not disadvantages.

When people say that IPv6 can't be deployed in ISPs, in enterprise
networks, in content providers, in home networks, or in mobile networks
because it lacks feature X, we'd do well to remember that there are large
deployments of IPv6 in all these areas. I know, because I've personally
been involved in all of the above. In my experience, excuses for not
deploying IPv6 are, to a great extent, just that: excuses. They have no
relationship to the actual reason for not deploying it, which is, and has
always been, "we see no benefit" (or, to a lesser extent, "our code doesn't
support it", and "our code has bugs" -- both of which are temporary). These
excuses mislead the IETF into thinking that the lack of IPv6 deployment
means that there is somehow something wrong with the protocol. This in turn
causes hand-wringing and standards-writing, but in my experience, that
doesn't help: when we remove an excuse, people move on to another excuse --
because the excuse wasn't the real reason anyway.

Continued tinkering with IPv6 - especially tinkering with it to make it
look more and more like IPv4 in order to reduce imagined "barriers to
adoption" - will just erode IPv6's long-term advantages by eliminating the
simplification, robustness, and benefits that IPv6 as it is today *does*
provide -- and it won't lead to adoption anyway, because lack of adoption
is not a technical issue.

What we need to do now is stick to the protocols as designed and wait until
the combination of ever-increasing pain caused by IPv4 exhaustion, and
exponentially-increasing IPv6 deployment in the Internet at large (or at
least in the consumer space), change the "there's no benefit" equation.
That *does* have the power to cause deployment in a way which changing the
standards will never have -- and as you put it, the more we change now, the
more we *delay* deployment, by causing vendors to write code that then
needs to be waited for, tested, and debugged before operators can deploy.

Personally, I think 6man has the duty to ensure that no radical changes go
into the core protocols until *real deployment experience* -- not of the "I
can't deploy because..." kind, but only of the "I deployed *and it didn't
work because...*" kind -- shows that there is really a gap in
functionality, and even then, to think extremely carefully whether the
long-term effects will be beneficial or not. We're hoping that this IPv6
thing is going to last us for the next 30 years. Let's not get too hung up
on the next 3.

Cheers,
Lorenzo

---

From: Sander Steffann <[email-masked]>
Date: Fri, 14 Mar 2014 00:49:58 +0900

Hi,

Op 13 mrt. 2014, om 23:27 heeft Lorenzo Colitti <[email-masked]> het volgende geschreven:

> Continued tinkering with IPv6 - especially tinkering with it to make it look more and more like IPv4 in order to reduce imagined "barriers to adoption" - will just erode IPv6's long-term advantages by eliminating the simplification, robustness, and benefits that IPv6 as it is today *does* provide -- and it won't lead to adoption anyway, because lack of adoption is not a technical issue.

I wholeheartedly agree. Thanks for putting it so clearly,
Sander

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 13 Mar 2014 16:20:25 +0000

> 	ready for widespread use until they stop changing 

With respect, if the changes you mentioned are considered fundamental changes to IPv6, the IETF has spent the past 25 years changing IPv4. Nobody anywhere should consider deploying IPv4 until we finish changing it.

---

From: Cb B <[email-masked]>
Date: Thu, 13 Mar 2014 09:29:31 -0700

On Mar 13, 2014 9:20 AM, "Fred Baker (fred)" <[email-masked]> wrote:
> With respect, if the changes you mentioned are considered fundamental
changes to IPv6, the IETF has spent the past 25 years changing IPv4. Nobody
anywhere should consider deploying IPv4 until we finish changing it.

+1 for Fred

RJ please dont confuse  excuses with reality.

If you can give me a real example of somebody with a real reason to not
deploy ipv6 i would be interested.

I can give you real examples of large and small mobile, docsis, dsl,
university, enterprise campus, ... networks that have deployed ipv6 in the
real world.  Ipv6 deployment is very real.

Evolution is how we run the internet. The relevant WG weigh all the pros
and cons for any change, no need for some paper tiger to freeze  evolution.
We dont want to be Académie française

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

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 13 Mar 2014 12:38:58 -0400

On Mar 13, 2014 9:20 AM, "Fred Baker (fred)" <[email-masked]> wrote:
> changes to IPv6, the IETF has spent the past 25 years changing IPv4.

We disagree that we've been changing IPv4 in similar ways 
oat a similar age.  Yes, IPv4 did change significantly
between the infamous Flag-day conversion from NCP and the
early 90s widespread adoption of CIDR.  However, major IPv4 changes,
such as CIDR, happened well prior to its 20th Anniversary.  

By contrast, major changes ARE being proposed for IPv6 
well AFTER its 20th Anniversary -- and not because the
existing IPv6 doesn't work well (which it does), but instead 
for the reasons that Lorenzo's reply to my note outlined.

>> +1 for Fred

Please see Lorenzo's response to my note, which I think was
more eloquent than mine (I fully agree with Lorenzo's note).

Yours,

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Mar 2014 06:51:39 +1300

> With respect, if the changes you mentioned are considered fundamental changes to IPv6, the IETF has spent the past 25 years changing IPv4. Nobody anywhere should consider deploying IPv4 until we fi…

Yes, my first thought was that in 1988 or so, when some of us
in European academia and research proposed to abandon the OSI dream
in favour of TCP/IP, the following two statements would both have been
plausible:

 The IETF keeps changing IPv4.  Clearly IPv4 is not yet
 ready for widespread use until they stop changing
 the specifications.

 The ISO keeps changing OSI.  Clearly OSI is not yet
 ready for widespread use until they stop changing
 the specifications.

I think we need to communicate that we are enhancing and
fine-tuning IPv6, not changing it.

I fully agree that changes which invalidate running code
must be avoided. No discussion.

    Brian

---

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

Ran,

You sent out 3 emails with partially overlapping topics - makes sense 
having particular discussions in a particular thread.
I think your reference below to "chanhing every ND implementation" is 
the same as in the thread on "IPv6 over radio links", and I've responded 
in that thread.

Below you also refer to "changing the IPv6 architecture that separates 
IID". Is this a reference to draft-carpenter-6man-why64?
I don't see anything in that draft which proposes to change anything - 
merely documenting why we have 64 bit IIDs.

Confused,
    Erik

---

From: t.petch <[email-masked]>
Date: Thu, 13 Mar 2014 18:22:29 +0000

--- Original Message -----
From: "Cb B" <[email-masked]>
To: "Fred Baker" <[email-masked]>
Cc: "RJ Atkinson" <[email-masked]>; <[email-masked]>
Sent: Thursday, March 13, 2014 4:29 PM
Nobody

Fred

I think that the key difference is that with IPv4, there was little else
that users could do - OSI, DECNet ?

With IPv6, most users have a choice - stay with IPv4.

I think that Ran accurately identifies one of the reasons for poor
deployment, tinkeritis, but that another reason is the sheer complexity
of IPv6 compared with IPv4.

Both topics surface here, and on v6ops, at intervals.

Tom Petch

+1 for Fred

I can give you real examples of large and small mobile, docsis, dsl,
university, enterprise campus, ... networks that have deployed ipv6 in
the
real world.  Ipv6 deployment is very real.

Evolution is how we run the internet. The relevant WG weigh all the pros
and cons for any change, no need for some paper tiger to freeze
evolution.
We dont want to be Académie française

CB

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 13 Mar 2014 14:37:34 -0400

> fine-tuning IPv6, not changing it.

Agreed, but we also need to be very careful to minimise changes 
to those that are really absolutely necessary - and those ought 
to be based on actual observed operational problems -- consistent 
with Lorenzo's email from earlier today.

> must be avoided. No discussion.

I'm happy we agree on that.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 13 Mar 2014 14:39:37 -0400

On 13  Mar 2014, at 14:19 , Erik Nordmark wrote:
> Below you ...
> Is this a reference to draft-carpenter-6man-why64?

It is a reaction to some folks' comments on the IPv6 list
in the past fortnight suggesting major changes to IID-related
IPv6 specifications.

Ran

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Mar 2014 22:29:49 +0100

Le 13/03/2014 15:27, Lorenzo Colitti a écrit :
[...]
> RAs. No, you can't "save addresses" by making host subnets /120s (at
> least not easily). No, there is no RFC1918. No, ULAs are not the same as
> RFC1918. No, there is no NAT.

Yes there is IPv6 NAT an dit works just like in IPv4.

Alex

  But I think that in a lot of scenarios
> those are advantages, not disadvantages.
>
> because it lacks feature X, we'd do well to remember that there are
> large deployments of IPv6 in all these areas. I know, because I've
> personally been involved in all of the above. In my experience, excuses
> for not deploying IPv6 are, to a great extent, just that: excuses. They
> have no relationship to the actual reason for not deploying it, which
> is, and has always been, "we see no benefit" (or, to a lesser extent,
> "our code doesn't support it", and "our code has bugs" -- both of which
> are temporary). These excuses mislead the IETF into thinking that the
> lack of IPv6 deployment means that there is somehow something wrong with
> the protocol. This in turn causes hand-wringing and standards-writing,
> but in my experience, that doesn't help: when we remove an excuse,
> people move on to another excuse -- because the excuse wasn't the real
> reason anyway.
>
> adoption" - will just erode IPv6's long-term advantages by eliminating
> the simplification, robustness, and benefits that IPv6 as it is today
> *does* provide -- and it won't lead to adoption anyway, because lack of
> adoption is not a technical issue.
>
> What we need to do now is stick to the protocols as designed and wait
> until the combination of ever-increasing pain caused by IPv4 exhaustion,
> and exponentially-increasing IPv6 deployment in the Internet at large
> (or at least in the consumer space), change the "there's no benefit"
> equation. That *does* have the power to cause deployment in a way which
> changing the standards will never have -- and as you put it, the more we
> change now, the more we *delay* deployment, by causing vendors to write
> code that then needs to be waited for, tested, and debugged before
> operators can deploy.
>
> Personally, I think 6man has the duty to ensure that no radical changes
> go into the core protocols until *real deployment experience* -- not of
> the "I can't deploy because..." kind, but only of the "I deployed *and
> it didn't work because...*" kind -- shows that there is really a gap in
> thing is going to last us for the next 30 years. Let's not get too hung
> up on the next 3.
>
>
> Cheers,
> Lorenzo
>
>

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 14 Mar 2014 17:47:00 -0700 (PDT)

++1

"The Twelve Networking Truths"
https://tools.ietf.org/html/rfc1925

"(12) In protocol design, perfection has been reached not when there
is nothing left to add, but when there is nothing left to take away"

>________________________________
> From: Lorenzo Colitti <[email-masked]>
>To: RJ Atkinson <[email-masked]> 
>Cc: IETF IPv6 Mailing List <[email-masked]> 
>Sent: Friday, 14 March 2014 1:27 AM
>Subject: Re: A Plea for Architectural & Specification Stability with IPv6
> 
>
>
>For a long time I've believed that int the IETF we think that IPv6 is "not being deployed" because something is wrong with it. And so we keep changing it. But that's not the problem. IPv6 *is* being deployed, it will just take time. At current S-curve growth, we'll be done in 10 years.
>
>
>The original IPv6 architecture is sound, and the core protocols are perfectly deployable. They are a solid (though admittedly minor) improvement over IPv4. There is *nothing wrong* with the IPv6 architecture. Deploying IPv6 *as it is today* will, after a minor speed bump, lead to simplification, cost reduction, and increased transparency of a network that today is cluttered with brittle and expensive middleboxes (expensive both because they cost money and because they cost developer time for apps to work around).
>
>
>
>It's true that those that want IPv6 to be exactly like IPv4 are disappointed, because IPv6 is not IPv4. No, you can't do routing without RAs. No, you can't "save addresses" by making host subnets /120s (at least not easily). No, there is no RFC1918. No, ULAs are not the same as RFC1918. No, there is no NAT. But I think that in a lot of scenarios those are advantages, not disadvantages.
>
>
>When people say that IPv6 can't be deployed in ISPs, in enterprise networks, in content providers, in home networks, or in mobile networks because it lacks feature X, we'd do well to remember that there are large deployments of IPv6 in all these areas. I know, because I've personally been involved in all of the above. In my experience, excuses for not deploying IPv6 are, to a great extent, just that: excuses. They have no relationship to the actual reason for not deploying it, which is, and has always been, "we see no benefit" (or, to a lesser extent, "our code doesn't support it", and "our code has bugs" -- both of which are temporary). These excuses mislead the IETF into thinking that the lack of IPv6 deployment means that there is somehow something wrong with the protocol. This in turn causes hand-wringing and standards-writing, but in my experience, that doesn't help: when we remove an excuse, people move on to another excuse -- because the excuse
 wasn't the real reason anyway.
>What we need to do now is stick to the protocols as designed and wait until the combination of ever-increasing pain caused by IPv4 exhaustion, and exponentially-increasing IPv6 deployment in the Internet at large (or at least in the consumer space), change the "there's no benefit" equation. That *does* have the power to cause deployment in a way which changing the standards will never have -- and as you put it, the more we change now, the more we *delay* deployment, by causing vendors to write code that then needs to be waited for, tested, and debugged before operators can deploy.
>
>
>Personally, I think 6man has the duty to ensure that no radical changes go into the core protocols until *real deployment experience* -- not of the "I can't deploy because..." kind, but only of the "I deployed *and it didn't work because...*" kind -- shows that there is really a gap in functionality, and even then, to think extremely carefully whether the long-term effects will be beneficial or not. We're hoping that this IPv6 thing is going to last us for the next 30 years. Let's not get too hung up on the next 3.
>
>
>
>
>Cheers,
>Lorenzo
>

---

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

> Yes there is IPv6 NAT an dit works just like in IPv4.

We can't make it illegal, but we have already made it unnecessary.

  Brian

---

From: Jeroen Massar <[email-masked]>
Date: Sat, 15 Mar 2014 09:16:57 -0700

> We can't make it illegal, but we have already made it unnecessary.

Unnecessary for connection normal hosts, but let me admit, that I
recently found a situation where it was actually useful to have Linux's
NAT function for IPv6: forwarding connections in a proxy-style method.

This way I was able to setup a load-balanced forwarding setup for
various services without having to modify the backend systems to
understand a special header (eg X-Forwarded-For) for proper tracking of
too-many-connections and mere logging.

Note that the backend boxes actually do have their own global IPv6
address, one might just not want to expose to the world all the time.

As such, NAT has it's uses; they just should not be forced upon
end-users by the providers that they are using.

More annoyingly are the providers that will force-change your IP address
space every 24 hours; which will make people want to have NAT to avoid
renumbering.... and with 6rd, which is dependent on the IPv4 address,
this is already a reality in quite some places unfortunately.

Greets,
 Jeroen

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Mar 2014 05:38:04 +1300

> too-many-connections and mere logging.

Try RFC 7098?

   Brian

---

From: Jeroen Massar <[email-masked]>
Date: Sat, 15 Mar 2014 09:50:15 -0700

On 2014-03-15 09:38, Brian E Carpenter wrote:
[..]
>> too-many-connections and mere logging.

The flow-label would just add an extra tracking parameter in the NAT or
maybe better said 'connection tracker/translator' table.

I thus see little gain in adding something like that.
Also I don't know of any device actually having support for that.

Greets,
 Jeroen

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 15 Mar 2014 19:54:55 +0100

Le 15/03/2014 08:31, Brian E Carpenter a écrit :
>> Le 13/03/2014 15:27, Lorenzo Colitti a écrit : [...]
>>> disappointed, because IPv6 is not IPv4. No, you can't do routing
>>> without RAs. No, you can't "save addresses" by making host
>>> subnets /120s (at least not easily). No, there is no RFC1918. No,
>>> ULAs are not the same as RFC1918. No, there is no NAT.
>>

Hi Brian,

I agree with this in a sense: IPv6 address space is huge and hence the
IPv4 NAT is unnecessary.  IPv6 being embraced in more and more places is
a witness of this success.  It solves the IPv4 depletion problem in a
more Internet way than the architecturally e2e impossible way of NAT IPv4.

But, until cellular and some DSL operators provide something shorter
than a single /64 to a single SIM end user, or alternatively the
SLAAC/WiFi changes its EUI-64/64 IID stance, the IPv6 NAT is a viable
solution.

I consider it seriously when connecting any mobile network to the
Internet - like a multi-subnet LAN of a cheap vehicle, or a WPAN, or a
fixed sensor network, or a fixed hotspot in a remote area.

Alex

>>> When people say that IPv6 can't be deployed in ISPs, in
>>> enterprise networks, in content providers, in home networks, or
>>> in mobile networks because it lacks feature X, we'd do well to
>>> remember that there are large deployments of IPv6 in all these
>>> areas. I know, because I've personally been involved in all of
>>> the above. In my experience, excuses for not deploying IPv6 are,
>>> to a great extent, just that: excuses. They have no relationship
>>> to the actual reason for not deploying it, which is, and has
>>> always been, "we see no benefit" (or, to a lesser extent, "our
>>> code doesn't support it", and "our code has bugs" -- both of
>>> which are temporary). These excuses mislead the IETF into
>>> thinking that the lack of IPv6 deployment means that there is
>>> somehow something wrong with the protocol. This in turn causes
>>> hand-wringing and standards-writing, but in my experience, that
>>> doesn't help: when we remove an excuse, people move on to another
>>> excuse -- because the excuse wasn't the real reason anyway.
>>>
>>> Continued tinkering with IPv6 - especially tinkering with it to
>>> make it look more and more like IPv4 in order to reduce imagined
>>> "barriers to adoption" - will just erode IPv6's long-term
>>> advantages by eliminating the simplification, robustness, and
>>> benefits that IPv6 as it is today *does* provide -- and it won't
>>> lead to adoption anyway, because lack of adoption is not a
>>> technical issue.
>>>
>>> What we need to do now is stick to the protocols as designed and
>>> wait until the combination of ever-increasing pain caused by IPv4
>>> exhaustion, and exponentially-increasing IPv6 deployment in the
>>> Internet at large (or at least in the consumer space), change the
>>> "there's no benefit" equation. That *does* have the power to
>>> cause deployment in a way which changing the standards will never
>>> have -- and as you put it, the more we change now, the more we
>>> *delay* deployment, by causing vendors to write code that then
>>> Personally, I think 6man has the duty to ensure that no radical
>>> changes go into the core protocols until *real deployment
>>> experience* -- not of the "I can't deploy because..." kind, but
>>> only of the "I deployed *and it didn't work because...*" kind --
>>> shows that there is really a gap in functionality, and even then,
>>> to think extremely carefully whether the long-term effects will
>>> be beneficial or not. We're hoping that this IPv6 thing is going
>>> to last us for the next 30 years. Let's not get too hung up on
>>> the next 3.
>>>
>>>
>>> Cheers, Lorenzo
>>>
>>>
>>> [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: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Mar 2014 21:07:25 +1300

> I thus see little gain in adding something like that.

You don't add it to NAT. You use it for load balancing with
native global addressing, so that you don't need NAT.

> Also I don't know of any device actually having support for that.

Yes, it's a relatively new RFC, but it was reviewed by load
balancer people.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Mar 2014 21:08:41 +1300

On 16/03/2014 07:54, Alexandru Petrescu wrote:
> than a single /64 to a single SIM end user, 

Yes, that is a shocking error in the 3GPP world, but that doesn't
mean that the IETF should legitimise it.

    Brian

> or alternatively the

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 16 Mar 2014 19:23:02 +0900

> mean that the IETF should legitimise it.

It's a hell of a lot better than the /128 they started with...

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 16 Mar 2014 23:02:12 +1100

Brian, 

>mean that the IETF should legitimise it.

=> The IETF, represented in the IPv6 (ng) at the time specifically asked
for the /64 to be allocated by 3GPP. This is documented in RFC 3314.

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 16 Mar 2014 23:11:42 +1100

>>adoption is not a technical issue.

=> Thank you for this sentence, whoever said it! I have been working on
deployment issues with operators and I never saw this imagined barrier. If
anything, I see operations people excited about learning a new technology.
Maybe I was lucky. 

Hesham

---

From: joel jaeggli <[email-masked]>
Date: Sun, 16 Mar 2014 07:51:07 -0700

On 3/16/14, 1:08 AM, Brian E Carpenter wrote:
...
> mean that the IETF should legitimise it.

Shock implies surprise.  3gpp release 8 was frozen 7.75 years ago.
version 11 has has dhcpv6 PD.

---

From: joel jaeggli <[email-masked]>
Date: Sun, 16 Mar 2014 08:47:14 -0700

>> On 2014-03-15 09:38, Brian E Carpenter wrote:

<snip>

> Yes, it's a relatively new RFC, but it was reviewed by load

It would be super helpful if you're going  use it for load-balancing if
it weren't optional...

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Mar 2014 07:37:13 +1300

> for the /64 to be allocated by 3GPP. This is documented in RFC 3314.

I suspect that was in response to the original /128. But the
recommendation (in section 2.3) is "one or more /64 prefixes".

> version 11 has has dhcpv6 PD.

Well, in this case the surprise was some years ago. Supporting
PD is of course a solution.

   Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 16 Mar 2014 19:42:44 +0100

Le 16/03/2014 13:02, Hesham Soliman a écrit :
>
> Brian,
>
>>>
>>> I agree with this in a sense: IPv6 address space is huge and
>>> hence the IPv4 NAT is unnecessary.  IPv6 being embraced in more
>>> and more places is a witness of this success.  It solves the IPv4
>>> depletion problem in a more Internet way than the architecturally
>>> e2e impossible way of NAT IPv4.
>>>
>>> But, until cellular and some DSL operators provide something
>>> shorter than a single /64 to a single SIM end user,
>>
> => The IETF, represented in the IPv6 (ng) at the time specifically
> asked for the /64 to be allocated by 3GPP. This is documented in RFC
> 3314.

This recommendation seems to not have considered the practical
realization of of mobile hotspots.

Maybe because in year 2002 when that RFC 3314 was issued there were no
cheap smartphones with cellular and wifi interfaces.  Nowadays these are
common, and the practical experimentation with them shows its
qualifications are less relevant.

For example, RFC3314 says:
> Because multiple IPv6 hosts may attach through a 3GPP handset, the
> IPv6 WG recommends that one or more /64 prefixes should be assigned
> to each primary PDP context.  This will allow sufficient address
> space for a 3GPP-attached node to allocate privacy addresses and/or
> route to a multi-link subnet [MULTLINK], and will discourage the use
> of NAT within 3GPP-attached devices.

This paragraph seems to miss the fact that the privacy addresses are
also 64-length IIDs and that multi-link subnets have issues (see the
64share draft).

This paragraph discourages the use of IPv6 NAT and offers alternatives
which are not valid either.

This RFC is also silent about the only real Prefix Delegation (DHCP):
> Note that [PREFDEL] cannot be considered stable and has not, at this
> stage, been adopted by the IPv6 WG as a WG document.

All in all the RFC is no alternative to IPv6 NAT and does not render it 
unnecessary.

Alex

>
> Hesham
>
>
>>
>> Brian
>>
>>> or alternatively the SLAAC/WiFi changes its EUI-64/64 IID stance,
>>> the IPv6 NAT is a viable solution.
>>>
>>> I consider it seriously when connecting any mobile network to
>>> the Internet - like a multi-subnet LAN of a cheap vehicle, or a
>>> WPAN, or a fixed sensor network, or a fixed hotspot in a remote
>>> area.
>>>
>>> Alex
>>>
>>>>
>>>> Brian
>>>>
>>>>>
>>>>> Alex
>>>>>
>>>>>
>>>>>> enterprise networks, in content providers, in home
>>>>>> networks, or in mobile networks because it lacks feature X,
>>>>>> we'd do well to remember that there are large deployments
>>>>>> of IPv6 in all these areas. I know, because I've personally
>>>>>> been involved in all of the above. In my experience,
>>>>>> excuses for not deploying IPv6 are, to a great extent, just
>>>>>> that: excuses. They have no relationship to the actual
>>>>>> reason for not deploying it, which is, and has always been,
>>>>>> "we see no benefit" (or, to a lesser extent, "our code
>>>>>> doesn't support it", and "our code has bugs" -- both of
>>>>>> thinking that the lack of IPv6 deployment means that there
>>>>>> is somehow something wrong with the protocol. This in turn
>>>>>> causes hand-wringing and standards-writing, but in my
>>>>>> experience, that doesn't help: when we remove an excuse,
>>>>>> people move on to another excuse -- because the excuse
>>>>>> Continued tinkering with IPv6 - especially tinkering with
>>>>>> it to make it look more and more like IPv4 in order to
>>>>>> reduce imagined "barriers to adoption" - will just erode
>>>>>> IPv6's long-term advantages by eliminating the
>>>>>> simplification, robustness, and benefits that IPv6 as it is
>>>>>> today *does* provide -- and it won't lead to adoption
>>>>>> anyway, because lack of adoption is not a technical issue.
>>>>>>
>>>>>> What we need to do now is stick to the protocols as
>>>>>> designed and wait until the combination of ever-increasing
>>>>>> pain caused by IPv4 exhaustion, and
>>>>>> exponentially-increasing IPv6 deployment in the Internet at
>>>>>> large (or at least in the consumer space), change the
>>>>>> "there's no benefit" equation. That *does* have the power
>>>>>> to cause deployment in a way which changing the standards
>>>>>> will never have -- and as you put it, the more we change
>>>>>> now, the more we *delay* deployment, by causing vendors to
>>>>>> write code that then needs to be waited for, tested, and
>>>>>> debugged before operators can deploy.
>>>>>>
>>>>>> Personally, I think 6man has the duty to ensure that no
>>>>>> radical changes go into the core protocols until *real
>>>>>> deployment experience* -- not of the "I can't deploy
>>>>>> because..." kind, but only of the "I deployed *and it
>>>>>> didn't work because...*" kind -- shows that there is really
>>>>>> a gap in functionality, and even then, to think extremely
>>>>>> carefully whether the long-term effects will be beneficial
>>>>>> or not. We're hoping that this IPv6 thing is going to last
>>>>>> us for the next 30 years. Let's not get too hung up on the
>>>>>> next 3.
>>>>>>
>>>>>>
>>>>>> Cheers, Lorenzo
>>>>>>
>>>>>>
>>>>> IETF IPv6 working group mailing list [email-masked]
>>>>> Administrative Requests:

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 16 Mar 2014 19:44:47 +0100

> version 11 has has dhcpv6 PD.

Yes, and there is no implementation of it to any operator I am aware of.

Whereas IPv6 NAT is not specified anywhere but its implementation is 
widely available.

Alex

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 16 Mar 2014 21:52:01 +0000

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

> mean that the IETF should legitimise it.

The IETF needs to deal with reality, though. I see a 64-bit IID mandate, the existence of /64 prefix assignments to customers, and opposition to IPv6 NAT as being internally inconsistent. Something has to give. I'm starting to see that IPv6 NAT will become popular in short order.

Bert

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 17 Mar 2014 10:27:46 +1100

>recommendation (in section 2.3) is "one or more /64 prefixes".

=> Yes of course they can allocate many /64. In reality I suspect that
will not happen often, at least in the mid-term, but nothing in the spec
stops it. 

Hesham

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 17 Mar 2014 10:59:38 +0900

On Mon, Mar 17, 2014 at 6:52 AM, Manfredi, Albert E <
[email-masked]> wrote:

> The IETF needs to deal with reality, though. I see a 64-bit IID mandate,
> the existence of /64 prefix assignments to customers, and opposition to
> IPv6 NAT as being internally inconsistent. Something has to give. I'm
> starting to see that IPv6 NAT will become popular in short order.
>

In what scenario do you see this as being necessary?

   - For residential ISPs, there's DHCPv6 PD (and all ISPs I'm aware of are
   handing out larger than /64, either by default, or if the customer CPE
   advertises in a DHCPv6 PD hint that it would like larger than /64).
   - For pre-rel10 3GPP links with a fixed allocation size of /64,
   there's draft-ietf-v6ops-64share

Anything else?

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 17 Mar 2014 13:45:15 +1100

>qualifications are less relevant.

=> If you mean multi-link hot spots (which are still not the norm in any
way) then it should be straight forward for 3GPP to support DHCP-PD. I
don¹t see much for us to do here about that given that the solutions
already exist. That recommendation was just that at a given time, nothing
to prevent 3GPP from adapting to changing realities.

Hesham

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 17 Mar 2014 12:09:53 +0900

> Whereas IPv6 NAT is not specified anywhere but its implementation is

I don't think it matters whether it's "widely available", I think it
matters whether it's "widely used".

IPv6 support has been widely available for well over a decade, but I think
everyone would agree that for most of that time it was not widely used.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 17 Mar 2014 06:49:24 +0100

Le 17/03/2014 03:45, Hesham Soliman a écrit :
> way) then it should be straight forward for 3GPP to support DHCP-PD.

I meant any network attached to a cellular using a single SIM and that 
has several /64 subnets.

This is to distinguish it from cases of use of the 64share draft that 
only work with a single such subnet.

And, unless the recommentation for 3GPP to support DHCP-PD materializes 
into deployment the documents per se are of little use, I think.

But I agree with you the 3GPP specs do say DHCP PD.

> to prevent 3GPP from adapting to changing realities.

Ok.

Alex

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 17 Mar 2014 17:31:17 +0000

Residential ISPs who are stingy with their prefix, mobile hotspots, and any of a host of new applications, such as in-vehicle communications and IoT in general. Situations in which it is hard to predict what the subnet architecture will look like this early on. Mandating 64-bit IIDs seems like a sure way to either have to request more prefixes more frequently, or what the heck, using a NAT makes this simpler.

If every household and every IoT platform (e.g. automobile) were given a /48, it seems unlikely (to me, as of today) that IIDs less than 64 bits would ever be needed. The problem is, it seems even more unlikely that every such platform is going to be given a /48. So if 64-bit IIDs are going to become mandatory, the only option for future growth is going to be the NAT.

Too much depends on how these IoT systems evolve. For example, are refrigerators, electrical breaker boxes, and home HVAC systems going to be requesting /56 prefixes? I’d say, each of these would definitely need prefixes </64. So individual households have to be given something like /48 right off the bat, not just /56. Is this likely? If we guess wrong today, with IIDs fixed at 64 bits, the only options are renumbering or NATs.

Bert

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Sunday, March 16, 2014 10:00 PM
To: Manfredi, Albert E
Cc: Brian E Carpenter; [email-masked]
Subject: Re: there _is_ IPv6 NAT - just look for it

On Mon, Mar 17, 2014 at 6:52 AM, Manfredi, Albert E <[email-masked]<mailto:[email-masked]>> wrote:
The IETF needs to deal with reality, though. I see a 64-bit IID mandate, the existence of /64 prefix assignments to customers, and opposition to IPv6 NAT as being internally inconsistent. Something has to give. I'm starting to see that IPv6 NAT will become popular in short order.

  *   For residential ISPs, there's DHCPv6 PD (and all ISPs I'm aware of are handing out larger than /64, either by default, or if the customer CPE advertises in a DHCPv6 PD hint that it would like larger than /64).
  *   For pre-rel10 3GPP links with a fixed allocation size of /64, there's draft-ietf-v6ops-64share
Anything else?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Mar 2014 09:45:28 +1300

On 18/03/2014 06:31, Manfredi, Albert E wrote:
> If every household and every IoT platform (e.g. automobile) were given a /48, 

We have 35 trillion of them in the current allocation to IANA, so I don't
see why there's a problem. In any case a /56 would be adequate.

> it seems unlikely (to me, as of today) that IIDs less than 64 bits would ever be needed. The problem is, it seems even more unlikely that every such platform is going to be given a /48. So if 64-bit IIDs are going to become mandatory, the only option for future growth is going to be the NAT.
> 
> Too much depends on how these IoT systems evolve. 

Indeed it does. Personally I'd like my domestic system to be very solidly
isolated from the Internet, probably by an application layer entity.
That doesn't call for NAT, even though it might call for ULA.

   Brian

> For example, are refrigerators, electrical breaker boxes, and home HVAC systems going to be requesting /56 prefixes? I’d say, each of these would definitely need prefixes </64. So individual households have to be given something like /48 right off the bat, not just /56. Is this likely? If we guess wrong today, with IIDs fixed at 64 bits, the only options are renumbering or NATs.
> 
> Bert
> 
>

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 17 Mar 2014 22:16:29 +0000

> From: Brian E Carpenter [mailto:[email-masked]]

> That doesn't call for NAT, even though it might call for ULA.

Sure, but what you're doing is assuming the problem away. Agree that ULAs are a good solution for isolated networks, or networks behind an application layer firewall, and they have that 64-bit IID. And what the heck, in that scenario, you can always stick with IPv4 and RFC 1918!

Bert

---

From: Cb B <[email-masked]>
Date: Mon, 17 Mar 2014 15:22:00 -0700

On Mar 17, 2014 3:16 PM, "Manfredi, Albert E" <[email-masked]>
wrote:
> Sure, but what you're doing is assuming the problem away. Agree that ULAs
are a good solution for isolated networks, or networks behind an
application layer firewall, and they have that 64-bit IID. And what the
heck, in that scenario, you can always stick with IPv4 and RFC 1918!

Not when the space required for that isolated network is larger than the
space in rfc1918, or rfc 1918 space is already used up in another part of
the network.

CB

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 18 Mar 2014 11:58:10 +0900

On Tue, Mar 18, 2014 at 2:31 AM, Manfredi, Albert E <
[email-masked]> wrote:

>  Residential ISPs who are stingy with their prefix,
>

You can't fix that particular problem. If you allow shorter than /64, some
stingy ISP is going to assign you shorter than /64. That becomes an arms
race until you get to /128 and then you have to implement NAT anyway.

> mobile hotspots, and any of a host of new applications, such as in-vehicle
> communications and IoT in general.
>

Is there a reason why this stuff can't be bridged at L2?

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 18 Mar 2014 14:05:36 +1100

>
>mobile hotspots, and any of a host of new applications, such as
>in-vehicle communications and IoT in general.
>
>
>
>
>

=> I haven¹t seen a general case for mobile hot spots that need multiple
IP subnets, so I don¹t see a massive case there for shorter prefixes. But
you can imagine a case easily enough for in-vehicle communications where
it makes sense to have complete network separation between the vehicle¹s
internals and the passengers traffic. Sure you can still bridge everything
but IP sub-netting gives you in-built separation for IP layer traffic like
ND ..etc relatively easily. So it would be good to support that.

I just don¹t understand why all of this can¹t be done today for mobile
routers with PD! People keep talking about it not being deployed but all
that means is that there hasn¹t been enough demand for it yet. I don¹t see
the IETF¹s role as an organisation as one that dedicates itself to
developing temporary workarounds. The salutations are there for people to
deploy. 

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 18 Mar 2014 14:08:21 +1100

-----Original Message-----
From: Hesham Soliman <[email-masked]>
Date: Tuesday, 18 March 2014 2:05 pm
To: Lorenzo Colitti <[email-masked]>, "Manfredi, Albert E"
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: there _is_ IPv6 NAT - just look for it

>developing temporary workarounds. The salutations are there for people to
                                        ^^^^^ I meant solutions of course.
Looks like my auto-correct was developed by a yoga instructor :)

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 18 Mar 2014 03:29:19 +0000

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 

>IP subnets,

No, actually that was meant to be mobile devices which are assigned a /64 each, being used as mobile hotspots. They wouldn't require multiple subnets, typically, but they would require multiple hosts on their /64 prefix.

Lorenzo's suggestion of doing some of this at L2 is quite valid, and I've been doing it that way for years, in practice. However it ain't exactly plug and play. But yes, for things like in-car comms, I can see systems taking that route.

Assigning a /56 to such platforms as Brian C suggests is okay in a pinch, but I'm not sure that 256 subnets are exactly ample for the future. It really all depends how things evolve. Imagine, for example, attaching stress sensors and strain gauges to multiple critical components of cars, buses, trains, planes, and ships, to alert operators, and/or their maintenance depots, before something breaks. It seems to me that this type of future could quickly invalidate what we might consider ample address space today.

Bert

>But

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Mar 2014 20:42:37 +1300

> Is there a reason why this stuff can't be bridged at L2?

I don't buy luxury cars, but I have read that such cars have
multiple on-board LANs using diverse (non-EUI-48) technologies
even today. I imagine the same will apply in many IoT scenarios.
Therefore, L2 bridging is not the answer.

    Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 18 Mar 2014 09:25:26 +0100

Le 18/03/2014 03:58, Lorenzo Colitti a écrit :
> On Tue, Mar 18, 2014 at 2:31 AM, Manfredi, Albert E
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> You can't fix that particular problem. If you allow shorter than /64,
> some stingy ISP is going to assign you shorter than /64. That becomes an
> arms race until you get to /128 and then you have to implement NAT anyway.
>

Birdging works only between compatible L2s, right?

In a vehicle there are numerous L2s, sometimes incompatible.

Alex

---

From: Glen Turner <[email-masked]>
Date: Sun, 23 Mar 2014 23:04:32 +1030

As one small example, we were happily using ::1, ::2, … for router addressing on EUI-64 subnets. This is operationally nice, as IP addressing ends up in various places in a router configuration and being able to swap out a failed interface without needing to check to see if the configuration may need altering is robust.

Recently a vendor which used to support this no longer does: the router's address is formed using its MAC address if EUI-64 is configured, there is no override. When we lodged a bug we were informed that the change was deliberate, to track changes in IPv6 specifications. I didn't pursue this with the vendor further, but it is a good demonstration of the risks of altering the IPv6 specification at this stage of its deployment.

-glen

---

From: Ole Troan <[email-masked]>
Date: Sun, 23 Mar 2014 13:42:34 +0100

Glen,

> Recently a vendor which used to support this no longer does: the router's address is formed using its MAC address if EUI-64 is configured, there is no override. When we lodged a bug we were informe…

that seems like a misunderstanding. manual configuration of addresses has always been part of the IPv6 addressing architecture.

cheers,
Ole

---

From: Glen Turner <[email-masked]>
Date: Sun, 23 Mar 2014 23:04:32 +1030

-glen

---

From: Glen Turner <[email-masked]>
Date: Mon, 24 Mar 2014 07:31:15 +1030

> that seems like a misunderstanding. manual configuration of addresses has always been part of the IPv6 addressing architecture.

Hello Ole,

It's not a statically addressed subnet, it's a EUI-64 autoconf subnet.

Operationally it is extremely useful to select the router's address, overriding autoconf for that address whilst allowing other machines to autoconf as per usual. Autoconfing the router's address escalates a simple "remote hands card replacement" into "engineer to examine configuration and test operation of all IPv6 router features after card replacement" because of the possibility that the interface's address is mentioned in the router's configuration (ACLs, source address for protocols, etc).

-glen

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Mar 2014 11:18:32 +1300

> It's not a statically addressed subnet, it's a EUI-64 autoconf subnet.

Regardless, there's no recent spec change that "MUST NOT"s small integer
IIDs, afaik.

   Brian

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 23 Mar 2014 23:16:20 +0000

Glen,

From: ipv6 [mailto:[email-masked]] On Behalf Of Glen Turner
Sent: Sunday, March 23, 2014 5:01 PM
To: Ole Troan
Cc: 6man WG; RJ Atkinson
Subject: Re: A Plea for Architectural & Specification Stability with IPv6

>Operationally it is extremely useful to select the router's address, overriding autoconf for that address whilst allowing other machines to autoconf as per usual. Autoconfing the router's address >escalates a >simple "remote hands card replacement" into "engineer to examine configuration and test operation of all IPv6 router features after card replacement" because of the possibility that >the interface's address is >mentioned in the router's configuration (ACLs, source address for protocols, etc).

Interesting.  If I understand the issue correctly, here is my perspective.  ACL and source address for protocols should use the network interface of the card to be immune to card replacement.  It is also realistic that if a card is replaced, some configuration may need to change  The router interface can also use SLAAC to obtain its ipv6 global address.  Just have the interface also participate in routing and routing updates routes on interface reset or card of the interface getting swapped.   An example from my Cisco router interface is included below.  "ipv6 rip rip enable" configuration has the interface participate in RIPng configured on the router.

interface TenGigabitEthernet4/1/0
 mac-address 0000.0101.9843
 ipv6 address autoconfig
 ipv6 enable
ipv6 rip rip enable
end

Hemant

---

From: Glen Turner <[email-masked]>
Date: Mon, 24 Mar 2014 12:39:20 +1030

Hemant Singh wrote:

> ACL and source address for protocols should use the network interface of the card to be immune to card replacement.

ACLs could use interface names, but none of the vendors I know offer a facility like:
  ipv6 access-list ILLUSTRATIVE-EXAMPLE
   permit My_IP(Ethernet0)

I can understand that from a vendor's point of view. It does seem like a rather fragile feature (you've got to remember to rewrite ACLs into the line card ASIC or TCAM every time a interface flaps and every time a SLAAC or DHCP address expires). Having said that, "permit My_IP(*)" would be a godsend to anyone writing code to protect the router from abuse.

>  It is also realistic that if a card is replaced, some configuration may need to change

Firstly, card swaps and router configuration changes are not done by the same people. Involving two groups of people in a card change leads to considerably more cost. Secondly, there's the issue of certainty: were all ACLs, etc updated? This gives a card swap a risk which didn't previously exist.

>  The router interface can also use SLAAC to obtain its ipv6 global address.

No point, you have to predict the SLAAC address to be able to protect the router against attacks on that address and then use that address in ACLs. So you get all the fragility and vulnerability to SLAAC-based attacks but don't get automated configuration of the entire interface-referencing configuration.

> mac-address 0000.0101.9843

Using locally-administered MAC addresses does seem the only reasonable way forward, but again this increases the cost of deployment of IPv6 compared with other protocols (now we need a scheme for assigning local MAC addresses).

Of course there is an Internet-Draft in the works to remove the relationship between MAC address and the interface ID. I would have liked that draft or draft-gont-6man-deprecate-eui64-based-addresses to SHOULD allow the static configuration of interface IDs within a subnet of host using draft-ietf-6man-stable-privacy-addresses.

I do take Brian's point:

> Regardless, there's no recent spec change that "MUST NOT"s small integer IIDs, afaik.

and so I will take this up with the vendor and ask which specification they were relying upon.

Best wishes to all,
glen

---

From: Tim Chown <[email-masked]>
Date: Mon, 24 Mar 2014 07:51:29 +0000

> Of course there is an Internet-Draft in the works to remove the relationship between MAC address and the interface ID. I would have liked that draft or draft-gont-6man-deprecate-eui64-based-address…

There is also the tokenised interface identifier method, which allows short IIDs to be statically configured.

http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-02

If there's interest, I'll renew the draft.  

Tim

---

From: Ole Troan <[email-masked]>
Date: Mon, 24 Mar 2014 11:26:06 +0100

Glen,

> It's not a statically addressed subnet, it's a EUI-64 autoconf subnet.

routers (as defined in RFC4861) don't autoconfigure addresses using SLAAC. that's a host function.
a router may automatically create an EUI-64 based interface-id, but this is based on configuration, not on SLAAC.
on an IPv6 link there are many ways of creating interface-identifiers. manually configured, EUI-64, random, etc. all of these can co-exist on a link.

> Operationally it is extremely useful to select the router's address, overriding autoconf for that address whilst allowing other machines to autoconf as per usual. Autoconfing the router's address e…

yes, indeed. I configure most of my router interfaces with interface-id <prefix>::1.
there is obviously nothing prohibiting that in the IPv6 addressing architecture, nor has anything around that changed, or dare I say will ever change.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Mar 2014 14:48:49 +1300

> on an IPv6 link there are many ways of creating interface-identifiers. manually configured, EUI-64, random, etc. all of these can co-exist on a link.

I suspect that needs to be written in bold letters in many
places. Unfortunately the mandatory language of RFC 2464 has
often been interpreted as meaning more than was intended.

    Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 25 Mar 2014 00:57:16 -0700 (PDT)

----- Original Message -----
> From: Ole Troan <[email-masked]>
> To: Glen Turner <[email-masked]>
> Cc: 6man WG <[email-masked]>; RJ Atkinson <[email-masked]>
> Sent: Monday, 24 March 2014 9:26 PM
> Subject: Link addressing (was: Re: A Plea for Architectural & Specification Stability with IPv6)
> 
>G len,
> 
>>>  that seems like a misunderstanding. manual configuration of addresses 
> has always been part of the IPv6 addressing architecture.
>> 
>>  Hello Ole,
>> 

Being pedantic, the SLAAC RFC (RFC4862) says that "it is expected that routers will generate link-local addresses using the mechanism described in this document."

The question I've wondered a bit about is what is the common operational or implementation practice when configuring manual addresses on routers.

For people who configure static addresses on router interfaces, do they actively switch SLAAC off for either individual prefixes, or for the whole interface? Switching SLAAC off for the whole interface means that if there is no static LL address, then the interface doesn't comply with the RFC4291 requirement for all IPv6 interfaces to have an LL address, and can't use any functions/protocols that rely on LLs. An interface probably shouldn't be able to be used for IPv6 if there are no LL addresses present.

Alternatively, if SLAAC is left enabled for the LL prefix, then there is likely to now be two LLs on the interface. Static configuration of an LL address would usually indicate preference for its use for all LL traffic over the SLAAC LL address, which may be a problem, because IIRC, RFC6724 doesn't place any preference for static addresses over SLAAC addresses.

> on an IPv6 link there are many ways of creating interface-identifiers. manually 
> configured, EUI-64, random, etc. all of these can co-exist on a link.
> 
>>  Operationally it is extremely useful to select the router's address, 
> overriding autoconf for that address whilst allowing other machines to autoconf 
> as per usual. Autoconfing the router's address escalates a simple 
> "remote hands card replacement" into "engineer to examine 
> configuration and test operation of all IPv6 router features after card 
> replacement" because of the possibility that the interface's address is 
> mentioned in the router's configuration (ACLs, source address for protocols, 
> etc).
> 
> there is obviously nothing prohibiting that in the IPv6 addressing architecture, 
> nor has anything around that changed, or dare I say will ever change.
> 
> cheers,
> 
> Ole
>

---

From: [email-masked]
Date: Tue, 25 Mar 2014 09:46:26 +0100 (CET)

> The question I've wondered a bit about is what is the common
> operational or implementation practice when configuring manual
> addresses on routers.
> 
> For people who configure static addresses on router interfaces, do
> they actively switch SLAAC off for either individual prefixes, or
> for the whole interface?

Answering only for myself, obviously:

- We use static /124 addresses on our router-router links, which means
we're pretty darn sure that SLAAC won't be working for anything other
than the link local address. We may switch to /127.
- Additionally, Juniper routers need explicit configuration to turn on
RA. We definitely don't configure this on our router-router links.
- Additionally, we're planning to explicitly turn off SLAAC on Cisco
routers for our router-router links.

> Alternatively, if SLAAC is left enabled for the LL prefix, then
> there is likely to now be two LLs on the interface. Static
> configuration of an LL address would usually indicate preference for
> its use for all LL traffic over the SLAAC LL address, which may be a
> problem, because IIRC, RFC6724 doesn't place any preference for
> static addresses over SLAAC addresses.

The static IPv6 addresses that we configure on router-router links are
*not* link local. Thus we don't have two link local addresses on the
interfaces.

Steinar Haug, AS 2116

---

From: Ole Troan <[email-masked]>
Date: Tue, 25 Mar 2014 10:00:59 +0100

Mark,

[...]

> Being pedantic, the SLAAC RFC (RFC4862) says that "it is expected that routers will generate link-local addresses using the mechanism described in this document."

perhaps we need better terminology here. it is useful to have a distinction between addresses that are formed based on appending an interface-identifier to a well-known prefix (link-local) or manually configured prefix, and how an address is formed based on receiving a /64 prefix in an RA and forming an address from that.

I prefer to use the term SLAAC for the latter. i.e. a host following the procedure in RFC4862 section 5.5.

> For people who configure static addresses on router interfaces, do they actively switch SLAAC off for either individual prefixes, or for the whole interface? Switching SLAAC off for the whole inter…

I don't understand what you mean by "switching SLAAC off" on an interface. on a router does that mean sending RAs with the A-flag in PIO off? or do you mean that a link-local or global address isn't formed based on an automatically generated interface-id (EUI-64, privacy, stable, ...)?

> Alternatively, if SLAAC is left enabled for the LL prefix, then there is likely to now be two LLs on the interface. Static configuration of an LL address would usually indicate preference for its u…

typically applications using link-local addresses, do their own source address selection.

for the implementation I'm most familiar with, we only allow a single link-local address per interface. by default that's based on the modified EUI-64 interface-identifier, but it can be manually set to whatever you like.
the same for global addresses. including a short-hand for specifying the length of the on-link prefix.

there is nothing stopping an implementation having multiple link-locals for an interface, e.g. there was at some point someone advocating that every global address should have a corresponding link-local. it isn't clear what the benefit of having multiple link-locals on an interface would be though.

cheers,
Ole

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 26 Mar 2014 00:47:07 -0700 (PDT)

----- Original Message -----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Tuesday, 25 March 2014 7:46 PM
> Subject: Re: Link addressing (was: Re: A Plea for Architectural &	Specification Stability with IPv6)
> 

So I'm wondering a bit why you don't statically set your link-local addresses too?

It seems to me that there are a number of possible motivations for statically setting IIDs for a router's interface addresses:

- because the prefix length isn't long enough to support SLAAC operation e.g., your /124 example

- the address is independent of the underlying interface link-layer address, allowing the interface to be changed without the IPv6 address changing

- the IID portion of the address is easier to type e.g, during troubleshooting

- When set for ULA or GUA prefixes, to give the interface a unique identifier so that AAAAs and PTRs can be created for them to assist with troubleshooting (although this could be done with LLs if you made sure their IIDs were unique across all of the router interfaces in your network)

I'd have thought if people had decided that they'll statically configure IIDs on router interfaces, they'd probably set the IID for all of the router's interfaces addresses, probably to the same value, for consistency and simplicity. As routing protocols will use LL addresses as next-hops and neighbor identifiers, it would seem to me that having the LL IIDs match the global or ULA IIDs on the link would be simpler and more operator friendly.

If LL address IIDs are set for consistency, that is the situation I was wondering about - how often is the SLAAC LL address left there perhaps due to not bothering to switch it off, and how is it possible to have the router prefer the static LL address for its own purposes such as IGP next-hops.

Regards,
Mark.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 26 Mar 2014 01:33:48 -0700 (PDT)

Hi Ole,

----- Original Message -----
> To: Mark ZZZ Smith <[email-masked]>
> Cc: Glen Turner <[email-masked]>; 6man WG <[email-masked]>; RJ Atkinson <[email-masked]>
> Sent: Tuesday, 25 March 2014 8:00 PM
>>>  routers (as defined in RFC4861) don't autoconfigure addresses using 
> SLAAC. 
>>>  that's a host function.
>> 
>>  Being pedantic, the SLAAC RFC (RFC4862) says that "it is expected that 
> routers will generate link-local addresses using the mechanism described in this 
> document."
> 
> perhaps we need better terminology here. it is useful to have a distinction 
> between addresses that are formed based on appending an interface-identifier to 
> a well-known prefix (link-local) or manually configured prefix, and how an 
> address is formed based on receiving a /64 prefix in an RA and forming an 
> address from that.
> 

I agree with the terminology problem. I was using "SLAAC" to mean an "address generation method" for the LL prefix, rather than the RA/PIO based address configuration method for hosts on the link, for prefixes other than LL, that is also part of "SLAAC".

> operational or implementation practice when configuring manual addresses on 
> routers.
>> 
>>  For people who configure static addresses on router interfaces, do they 
> actively switch SLAAC off for either individual prefixes, or for the whole 
> interface? Switching SLAAC off for the whole interface means that if there is no 
> static LL address, then the interface doesn't comply with the RFC4291 
> requirement for all IPv6 interfaces to have an LL address, and can't use any 
> functions/protocols that rely on LLs. An interface probably shouldn't be 
> able to be used for IPv6 if there are no LL addresses present.
> 
> I don't understand what you mean by "switching SLAAC off" on an 
> interface. on a router does that mean sending RAs with the A-flag in PIO off? or 
> do you mean that a link-local or global address isn't formed based on an 
> automatically generated interface-id (EUI-64, privacy, stable, ...)?
> 

Just switching off the SLAAC address generation method for the LL prefix for the router's own interface LL address i.e., if there is no statically set LL address, then the interface would not have a LL address, because the router interface now does not automatically generate an LL address. 

>>  Alternatively, if SLAAC is left enabled for the LL prefix, then there is 
> likely to now be two LLs on the interface. Static configuration of an LL address 
> would usually indicate preference for its use for all LL traffic over the SLAAC 
> LL address, which may be a problem, because IIRC, RFC6724 doesn't place any 
> preference for static addresses over SLAAC addresses.
> 
> for the implementation I'm most familiar with, we only allow a single 
> link-local address per interface. by default that's based on the modified 
> EUI-64 interface-identifier, but it can be manually set to whatever you like.

Ok, so it seems that for this implementation a static LL address replaces a SLAAC address generation method autoconfigured LL address. The issue of which LL address to use disappears because there is only ever one LL address.

On Linux for example, if you add a static LL address to an interface, the SLAAC LL address is left there, and both of them have infinite lifetimes, so lifetimes can't be used to distinguish the preference of one of the LL addresses over the other. Deleting the SLAAC LL address is possible, however there currently isn't a flag to stop it generating a new one when e.g., the interface is admin down/up'd or when the system next boots (there is an interface 'autoconf' flag, but that only disables autoconfiguration for non-LL prefixes).

> there is nothing stopping an implementation having multiple link-locals for an 
> interface, e.g. there was at some point someone advocating that every global 
> address should have a corresponding link-local. it isn't clear what the 
> benefit of having multiple link-locals on an interface would be though.
> 

While a rare situation, perhaps while renumbering from one statically configured LL addr to another to reduce disruption of things using the old LL address. In the implementation you mentioned, what impact and how severe is the impact of changing the single LL address e.g., does it cause OSPF and BGP neighbor adjacencies to be dropped and then re-established?

Thanks,
Mark.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 27 Mar 2014 11:17:08 -0700

> I prefer to use the term SLAAC for the latter. i.e. a host following the procedure in RFC4862 section 5.5.
Ole,

Agreed that the terminology we have isn't detailed enough to cover the 
finer details. It makes using SLAAC to refer to the reception of a 
prefix in a PIO with A=1. That leaves link-local address formation out 
of that definition.

We have some IID assignment and generation (modified EUI-64, static 
assignment, CGA, stable-privacy).
Then we have some set of prefixes that are already known on the router 
(fe80::/64, and also prefixes the router is configured to advertise to 
others for SLAAC).

I don't know how folks have implemented this on routers.
When we implemented this in Solaris it seemed helpful (even on a Solaris 
box configured as a router) to configure the IID separately (or get it 
from the MAC address), and then by default form the router's global 
addresses based on the prefixes the router is configured to advertise 
for SLAAC. (But NOT do anything with prefixes received in PIOs.)

The alternative would be to configure the router's advertised prefixes 
separately from the global addresses assigned to the router's 
interfaces, and that might be what other implementations do.

    Erik