static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1]

[Brian E Carpenter]

Hi Michael,

On 26-Oct-19 12:33, Michael Sturtz wrote:
> The problem with non-routable private ULA addressing is most vendor equipment doesn't support having a SLAAC or DHCP6 dynamic routable address and a static ULA address.

Yes. But that is the vendors' fault for not doing what the RFCs recommend. I don't really see how another RFC can fix that.

> 
> For simple home networks I suppose we could have a RFC that proposes the FE80 address space be used as the "static" address space for SOHO server addressing and locating such as local DNS or single server environments

By "simple" you mean with no interior routers, I guess. Yes, that's what I have; no RFC needed, just a well designed CE. Here's how it looks from Windows (and pretty much the same from Linux), just some magic numbers obscured:

Ethernet adapter Ethernet 4:

   Connection-specific DNS Suffix  . : fritz.box
   Description . . . . . . . . . . . : ASIX AX88772B USB2.0 to Fast Ethernet Adapter #2
   Physical Address. . . . . . . . . : xxxx
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2406:e002:xxxx:9301:80b2:5c79:2266:e431(Preferred)
   IPv6 Address. . . . . . . . . . . : fd63:45eb:dc14:0:80b2:5c79:2266:e431(Preferred)
   Temporary IPv6 Address. . . . . . : 2406:e002:xxxx:9301:243c:2e79:2618:e284(Preferred)
   Temporary IPv6 Address. . . . . . : fd63:45eb:dc14:0:243c:2e79:2618:e284(Preferred)
   Link-local IPv6 Address . . . . . : fe80::80b2:5c79:2266:e431%7(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.178.30(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Tuesday, 22 October, 2019 15:07:41
   Lease Expires . . . . . . . . . . : Tuesday, 5 November, 2019 13:43:40
   Default Gateway . . . . . . . . . : fe80::be05:43ff:fe8e:ce39%7
                                       192.168.178.1
   DHCP Server . . . . . . . . . . . : 192.168.178.1
   DHCPv6 IAID . . . . . . . . . . . : xxxx
   DHCPv6 Client DUID. . . . . . . . : xxxx
   DNS Servers . . . . . . . . . . . : fd63:45eb:dc14:0:be05:43ff:fe8e:ce39
                                       192.168.178.1

> or the end user equipment could just assume that it would be "static" given the common use of EUI-64 for the /64 portion (Windows excepted). 

EUI-64 is legacy at this point. You get stable addresses using a locally generated stable ID, 80b2:5c79:2266:e431 in the above case. Again - the RFCs already have all this; tell your vendors what you want, repeatedly and loudly, is all I can suggest.
 
> Right now, with the way it actually works in the field it is very disruptive every time the /64 is renumbered by the ISP  In my experience this happens way too often. 

Yes, we all agree about that. That's exactly why Fernando has written his draft. (Of course the ISP should be giving you a /48 or /56, but that's another existing RFC.)

> An end user should not have to go around and reboot devices, hunt around for the new printer IP and so on just because the ISP caused a renumber of their automatically assigned /64.  With SOHO networks which are the vast majority of end user networks we can't make it painful to use IPv6.  Even novice users can navigate the web UI of a home router and assign a static IP address to their network printer / scanner / copier etc. and it is very common to do this with IPv4.  The random ISP renumbering completely breaks that whole use case. Given the very long IPv6 addresses, DNS (name resolution) becomes very important for most end users.  Currently, this works fine on IPv4 because of NAT, PAT & RFC1918.  We don't have an operational answer for this on IPv6 at all.  For sites such as this I routinely get trouble tickets of random degraded connectivity that can be traced back to an ISP renumber event and one or more pieces of equipment didn't handle the renumber and could not connect to something else on the network or could not connect to something on the IPv6 internet.

Again, exactly why Fernando has written his draft. I notice that my Canon printer has fe80::2bb:c1ff:fe99:cd6 as well as 192.168.178.23. That's OK for a network with no interior routers. However, it looks as if the Canon utilities use IPv4. But in general IPv6 works well with this set up, even when my ISP has a glitch and I get flash-renumbered, as happened earlier this week.

Regards
    Brian

> 
> 
> 
> -----Original Message-----
> From: Brian E Carpenter <brian.e.carpenter at gmail.com> 
> Sent: Friday, October 25, 2019 4:02 PM
> To: Matthew Huff <mhuff at ox.com>; Nick Hilliard <nick at foobar.org>; Michael Sturtz <Michael.Sturtz at PACCAR.com>
> Cc: ipv6-ops at lists.cluenet.de; Fernando Gont <fernando at gont.com.ar>; Gert Doering <gert at space.net>
> Subject: static IPs [was Re: ipv6-ops Digest, Vol 159, Issue 1]
> 
> On 26-Oct-19 04:19, Matthew Huff wrote:
>> This is part of one of the many reasons corporate acceptance of IPv6 is so low. The IPv6 design appears to be oriented toward residential, ISP, and public wifi usages, with little care to corporate needs. Not only is static IPs desired, but in many cases required by regulation (Auditing, access, etc...). 
> 
> That is *not* a design issue. It's an ISP business practice issue, and it's why the RIRs have for a long time been assigning /48s for enterprises that want them.
> 
>> Things like DHCPv6 not supporting DNS server announcements is a good example (it's available recently, but not across all platforms). Private address may be a great thing for residential / public wifi, etc... but must be disabled in many, if not all, corporate environments.
> 
> Absolutely. They are a recommended default for the consumer market but I would expect most corporate deployments to disable them.
> 
>> Also, we have found that many software vendors certify their products for IPv6, but as soon as the PR release is done, their devs no longer test with IPv6 and their tech support almost always recommend disabling it the first time you open a ticket.
> 
> Again, it's a business issue over which paying customers have much more influence that anyone else, but only if they make it a commercial issue.
> 
> Progress will only come as more and more people stop putting IPv6 in the "too hard" basket. I really do understand that for people running actual services this is not a trivial thing, but it's a real chicken/egg situation, unfortunately. But the signs are good at last.
> 
> Regards
>     Brian Carpenter
> 
>>
>> -----Original Message-----
>> From: ipv6-ops-bounces+mhuff=ox.com at lists.cluenet.de 
>> <ipv6-ops-bounces+mhuff=ox.com at lists.cluenet.de> On Behalf Of Nick 
>> Hilliard
>> Sent: Friday, October 25, 2019 11:10 AM
>> To: Michael Sturtz <Michael.Sturtz at PACCAR.com>
>> Cc: ipv6-ops at lists.cluenet.de; Gert Doering <gert at space.net>; Fernando 
>> Gont <fernando at gont.com.ar>
>> Subject: Re: ipv6-ops Digest, Vol 159, Issue 1
>>
>> Michael Sturtz wrote on 25/10/2019 16:03:
>>> This sort of operational nonsense will limit the wider acceptance of 
>>> IPv6!  I am responsible research and for the documentation and 
>>> implementation of IPv6 for a Fortune 200 company.  We have locations 
>>> worldwide.  The allocation of unstable end network addresses 
>>> complicates the deployment and support of IPv6.
>> most service providers view this as a commercial issue rather than a protocol issue.  This is just an observation, btw.
>>
>> Nick
>>