Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

[Jen Linkova <[e-mail]>]

On Tue, Oct 29, 2019 at 9:36 AM Ole Troan <[e-mail]> wrote:
> >> Right. Instant/flash renumbering is not supported in IP networks.
> >
> > Oh. Surprise. After I've been doing it all the time....;)
>
> Oh great. So which services do you run in the network? Any issue with short DNS ttls?

Well, I'm quite lucky. First of all, I'm mostly renumbering networks
containing "clients" - networks which rarely need incoming
connections.

> Or do you only do this with MP-TCP / QUIC or only mosh style applications with a built in session layer?
> I presume you have a routed network with multiple routers and links as well?

Boring topologies mostly - two routers to provide first-hop
redundancy, two uplinks.
And - after I've done quite a bit of renumbering both dual-stack and
single-stack segments - IPv4 renumbering is much, much worse.
Sometimes you have to flap switchports.

>Ole, not sarcastic at all. ;-)

>
>
> >
> > Actually it would be helpful  to define requirements/expectations. I read it as:
> > R1: [MUST HAVE] after the renumbering host is able to open new connections
> > R2: [NICE TO HAVE] old connections survive the renumbering.
> >
> > IMHO we shall at least enumerate the most common scenarios where R1 is
> > not happening and look what can be done here.
> > If we have a scenario when hosts end up with totally broken connectivity we can:
> > 1) say 'oh just don't do that' - however before we do this (== produce
> > some BCPs) it's worth analysing if it's feasible and, more
> > importantly:
> >  --- is the party affected by the issue is the same party which is
> > supposed to follow the BCP?
> >  --- are we talking about 'fix all hosts'? (when did we deal last
> > time with the scenario 'a machine re-authenticated via 802.1x
> > successfully, changed the VLAN but kept the old IPv6 prefix'?
> > 2) See if there is a way to mitigate at least part of the problem by
> > making the protocol more robust (isn't all DNA work is actually in the
> > same problem space?)
> >
> >> IPv6 does nothing to help with this, well, assuming a network hiding behind NAT, it makes it harder.
> >> Apart from "does not work", what more can the IETF say or do here?
> >
> > Try to make the Internet work better, maybe? :)
> >
> >>> On 24 Oct 2019, at 12:43, Mark Smith <[e-mail]> wrote:
> >>>
> >>>
> >>>
> >>> On Thu, 24 Oct 2019, 20:59 Trevor Warwick, <[e-mail]> wrote:
> >>>
> >>> On Thu, 24 Oct 2019 at 09:18, Mark Smith <[e-mail]> wrote:
> >>>
> >>>
> >>> I thought about this in the exact context of the scenario of this draft. Although the design of the broadband deployment I worked on always planned to give out stable prefixes, I worked through this scenario and realised that so many complex issues disappear if you provide stable prefixes.
> >>>
> >>> Fundamentally, if an ISP is selling an always on link to the same location, then the addressing should be as permanent as the link delivery location is.
> >>>
> >>>
> >>> If you're an ISP today, and using DHCPv6-PD to hand out IPv6 prefixes, what are the possible scenarios if you don't try hard to keep the prefixes stable?
> >>>
> >>> Why don't you want to try hard? Not trying hard gives customers a bad experience. They're paying you to try hard to give them the best suitable service you can give them.
> >>>
> >>>
> >>> - You could be running a closed environment where all customers are forced to use your CPE, in which case you can make sure that your CPE has various   hacks added to try to cope with prefix instability and avoid customer hosts experiencing connectivity issues when prefixes change. Maybe you can make this work well enough, and advanced customers who don't want to use your CPE are just out of luck.
> >>>
> >>> - If you're in an environment where customers can chose their own CPE, then it seems almost guaranteed that there will be connectivity problems when the prefix changes, because many CPE implementations don't handle this situation at all. So you're then relying on hosts falling back seamlessly to IPv4, in order to continue to have connectivity. In which case, I'd wonder why you're bothering to provide an IPv6 service in the first place.
> >>>
> >>> See what I said about selling an always on service to a fixed location, and the addressing having the same amount of stability as the service and link itself.
> >>>
> >>> The reason this problem really exists is that ISPs have fundamentally continued to treat residential, always on broadband customers although they were still dial up customers. Nothing has changed - per BRAS (NAS) IP address pools, pool route aggregation at the router, customer gets a single IPv4 address when they attach, that can change each time they attach. PPPoE is making Ethernet connectivity resemble dial up connectivity.
> >>>
> >>> Now this dial up model is trying to be applied to semi-permanent IPv6 services, where it's even less applicable now that customers get their own routed address space on a semi-permanent link.
> >>>
> >>> Treat all customers as routed subnet SOHO customers, so they get the same prefix regardless of which BRAS they attach to. Move the route aggregation boundary to a higher level to e.g. a cluster of BRASes, or a region.
> >>>
> >>> Use an IPv6 address provisioning model that suites and matches the service they're paying for, not a nearly 30 year old dial up model.
> >>>
> >>> If your customers can BYO their CPE, then stable prefixes are the only choice.
> >>>
> >>> See slide 6.
> >>>
> >>> Residential IPv6 CPE - What Not to Do and Other Observations
> >>> https://www.slideshare.net/mobile/markzzzsmith/residential-ipv6-cpe-what-not-to-do-and-other-observations
> >>>
> >>>
> >>>
> >>>
> >>> I do think this is an important problem that needs to be solved, for this context and the others mentioned in the draft.
> >>>
> >>>
> >>> _______________________________________________
> >>> v6ops mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/v6ops
> >>> _______________________________________________
> >>> v6ops mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/v6ops
> >>
> >> _______________________________________________
> >> v6ops mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/v6ops
> >
> >
> >
> > --
> > SY, Jen Linkova aka Furry
>


--
SY, Jen Linkova aka Furry