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 <[email protected]>
> Sent: Friday, October 25, 2019 4:02 PM
> To: Matthew Huff <[email protected]>; Nick Hilliard <[email protected]>; Michael
> Sturtz <[email protected]>
> Cc: [email protected]; Fernando Gont <[email protected]>; Gert
> Doering <[email protected]>
> 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: [email protected]
>> <[email protected]> On Behalf Of Nick
>> Hilliard
>> Sent: Friday, October 25, 2019 11:10 AM
>> To: Michael Sturtz <[email protected]>
>> Cc: [email protected]; Gert Doering <[email protected]>; Fernando
>> Gont <[email protected]>
>> 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
>>
