Subject: DHCPv6-PD and Dynamic IPv6 Address Prefixes

From: Tony Whyman <[email-masked]>
Date: Sun, 8 Nov 2020 13:28:37 +0000

Looking through the large number of posts under  "the race to the 
bottom" thread, I can't see anyone complaining about the use of short 
lease IPv6 Prefixes and DHCPv6-PD. So here goes.

In the UK, the incumbent default ISP (BT) only gives its residential 
users a dynamic IPv6 prefix. The prefix is allocated whenever the router 
connects in using DHCPv6 PD and you typically get a different prefix 
each time. Some routers will ask for the previous prefix to be 
re-allocated and that request is usually honoured but, in my own 
experiments, by no means all will do this and, anyway, reset the router 
and you always get a new prefix.

The result is that your domestic subnet has to be re-numbered every time 
the router resets, with all the connectivity problems that that implies. 
If you search google for "BT Dynamic IPv6" you will find many examples 
of the problems this causes. NAT and DDNS are probably the only way of 
living with this - or moving to another ISP - which I did. My new ISP 
uses DHCPv6 PD properly. That is to give you the same prefix (a /48 no 
less) every time you connect thus avoiding the need for the user to key 
in a statically assigned IPv6 prefix.

IMHO, ISPs that use dynamic prefix assignments are at least as big a 
problem as any that might allocate a /128 and are here today rather than 
in some theoretical future. Perhaps IANA rules could be created here to 
bar the use of dynamic prefixes and to make this a contractual 
obligation when an ISP is allocated a prefix.

A similar problem also turned up in the ICAO working groups earlier this 
year. Some folks floated the idea that an aircraft's MNP could be 
allocated dynamically. There are many good reasons why aircraft should 
have a statically assigned MNPs, but a really strong one is that the 
last thing you need is renumbering an aircraft's subnets during a 
flight! That would be a major hazard resulting in an unexpected loss of 
communication for a significant period. The best way to avoid this is 
simply to design out the problem and use static MNP assignment.

This is arguably a general problem for mobiles. A mobile node may use 
many different wireless subnetworks during the same session. It may move 
between them in a break before make, or a make before break fashion, or 
even use several in parallel (multilink). The multilink case is the one 
most relevant to civil aviation, but the other cases also exist.

The one thing that no mobile user wants is to be allocated a new MNP 
every time a DHCPv6 PD is performed. That is just totally disruptive and 
probably is unworkable for multilink. On the other hand, what you want 
to do is to confirm your existing MNP with the default router on each 
wireless subnetwork visited. This is to ensure that it continues to be 
routeable.

That is a requirement for civil aviation and is one the intended 
functions of the OMNI draft.

You could bend DHCPv6 PD to confirm MNP use. However, that is a lot of 
overhead for a simple function. Adding MNP confirmation to the RS/RA 
exchange would seem to be the most efficient way of handling this.

Tony Whyman, MWA

---

From: Philip Homburg <[email-masked]>
Date: Sun, 08 Nov 2020 14:50:23 +0100

> The one thing that no mobile user wants is to be allocated a new
> MNP every time a DHCPv6 PD is performed. That is just totally
> disruptive and probably is unworkable for multilink. On the other
> hand, what you want to do is to confirm your existing MNP with the
> default router on each wireless subnetwork visited. This is to
> ensure that it continues to be routeable.

The problem of mapping between an aircraft and a MNP is similar to that of
a mobile phone and a phone number.

A mobile phone typically has a SIM card with has an IMSI and a phone number
is associated with the IMSI. We don't expect the phone number to change
except through specific action.

The same way a DHCPv6 server can return the aircrafts MNP based on the
iarcraft's identifier. There is no reason to dynamically allocate prefixes.
The only thing that needs to happen is that somebody needs to maintain
a database that lists which MNP is associated with a particular aircraft ID.

Assuming the database is public, then every DHCP server can get a copy of
the database.

---

From: Tony Whyman <[email-masked]>
Date: Sun, 8 Nov 2020 15:15:20 +0000

Yes, there is a requirement for such a database. The intent is that such 
a global database exists and that aircraft are separately configured 
with their MNP. Only if both the aircraft configuration and the database 
agree is datalink communication permitted. That way mis-configuration is 
quickly detected and the pilot can revert to voice communication without 
having to wait for a lengthy timeout. Aircraft authentication is also 
required - but that is a separate problem.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 08 Nov 2020 20:27:22 +0100

Most of the ISPs that do dynamic vs persistent is because lack of knowledge and "IPv4-mind-set". They should get a training, not change the standards to adapt to them. Offering persistent prefixes opens the door for more business to the ISP and less ops troubles.

See RIPE-690.

Regards,
Jordi
@jordipalet

El 8/11/20 14:29, "ipv6 en nombre de Tony Whyman" <[email-masked] en nombre de [email-masked]> escribió:

    Tony Whyman, MWA

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

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 8 Nov 2020 20:17:16 +0000

JORDI PALET MARTINEZ wrote on 08/11/2020 19:27:
> Most of the ISPs that do dynamic vs persistent is because lack of
> knowledge and "IPv4-mind-set". They should get a training, not change
> the standards to adapt to them. Offering persistent prefixes opens
> the door for more business to the ISP and less ops troubles.
this is, incidentally, a canard both in terms of rationale and claims.

If static IP addresses involved less operational overhead, they would be 
cheaper to provision and manage, and therefore would be the default 
service offering.

At best, whether they work well varies from service provider to service 
provider because static addressing models are fundamentally dependent on 
business models.  At best, they're a manageable nuisance for providers; 
at worst, they create long term, expensive headaches (routing table 
bloat, inability to migrate from end-point to end-point), which is why 
more often than not, providers tend to avoid them.

Nick

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 08 Nov 2020 21:35:59 +0100

I'm not saying that *all* the ISPs that choose to do non-persistent do it by lack of knowledge or IPv4-mind-set, but I 've trained about 75.000 folks on IPv6 since 2001 and probably 80% of them are ISPs, and what I got from them was:

1) I want to follow what I do with IPv4.
2) I don't understand why persistence give us more business.
3) We don't understand how to take advantage of persistence to offer more services.
4) We don't have the capability of offering those extra services.
5) My boss wants me to keep a differentiated service: non-persistent and small assignment to customers. If customers want persistence they need to pay more. If they want a /48 instead of /64 or /56 or /60, they need also to pay more. Clearly, again it is IPv4-mind-set.
6) I don't know if my equipment support persistence, or I don't know how to do it.

***** very few told me "my equipment or software" CAN'T DO IT.

I always told them "I fully agree that you only keep the same prefix if the customer is in the same BRAS, if the customer moves, unless you want to charge them for the extra route, they should agree on a prefix change". So, we aren't talking about "persistence" at all cost. That's a technical and cost balance. Normal customers, already understand that if they move their home, they need to "re-arrange" their ISP.

With persistent prefixes you have huge operational savings, unless your equipment is really bad designed - that's a vendor problem. You also avoid needing any logging of who is using what prefix at a given time. This is another huge saving.

All this was very well depicted in RIPE-690, unless we missed something, but I recall I drafted text for all what I learn from thousands of ISPs.

Changing people mind is very hard. Engineers can do it. Their boss not. Marketing and sale people are really impossible to get changed. They don't see IPv4 or IPv6, just money and if they can, even at the cost of increasing the operational complexity, have some customers paying for persistence and bigger assignments, they will do.

El 8/11/20 21:17, "Nick Hilliard" <[email-masked]> escribió:

    Nick

---

From: Mark Smith <[email-masked]>
Date: Mon, 9 Nov 2020 08:08:29 +1100

> more often than not, providers tend to avoid them.

How do you know this? Have you deployed PD?

Routing "bloat" is solved by aggregating customer routes at a higher level
than the individual BNG. Customers are assigned the same /56 (or /48)
within that aggregation domain, which may be something like a city or other
smaller or larger geographical region.

Customers are told they have 'stable' prefixes, not static prefixes,
meaning if they move they may get a different stable prefix. Moving really
means moving outside of the routing aggregation domain.

'Static' /56 (or /48) means the PD prefix follows the customer regardless
of where they move to and attach to your network, and there is a cost
premium to that because they not included in the routing aggregation
domain, and therefore need to pay for a route table slot in all of the
network's routers.

The idea of aggregation at a level within the network greater than all of
the individual the devices is older than IPv6 itself c.f. OSPF areas, BGP
ASNs.

If you want to aggregate on the BNGs, at the cost of less optimal routing,
you aggregate towards upstream, and then have direct "downstream" links
between the BNGs i.e. all BNGs attached to a downstream VLAN where you
trade the specific and exact /56s. You may inject more specific aggregates
upstream that are sub-aggregates of the whole aggregate to get better
traffic load distribution across the links into the BNGs.

Again, an idea older than IPv6 - this is the OSPF area routing model, where
there can be route aggregation towards the backbone routers, and all of the
exact specific routes within the area (or downstream VLAN). Can equally be
applied to BGP.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 9 Nov 2020 10:16:07 +1300

> more often than not, providers tend to avoid them.

All of which is why homenets and SOHOs would be better off to use ULAs for internal traffic. Dynamic WAN prefixes have always been part of the picture, despite Jordi's argument, and regardless whether DHCPv6-PD is used.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Sun, 08 Nov 2020 19:14:44 -0500

Tony Whyman <[email-masked]> wrote:
    > Looking through the large number of posts under  "the race to the bottom"
    > thread, I can't see anyone complaining about the use of short lease IPv6
    > Prefixes and DHCPv6-PD. So here goes.

    > In the UK, the incumbent default ISP (BT) only gives its residential users a
    > dynamic IPv6 prefix. The prefix is allocated whenever the router connects in
    > using DHCPv6 PD and you typically get a different prefix each time. Some
    > routers will ask for the previous prefix to be re-allocated and that request
    > is usually honoured but, in my own experiments, by no means all will do this
    > and, anyway, reset the router and you always get a new prefix.

I agree that this is an issue.
The fact that you can ask for the same prefix and get it, suggests that the
bug is at least partially on the side of the home router.
I'm curious what happens if you try asking for one you have never had.
Or that belongs to someone else :-)

    > The result is that your domestic subnet has to be re-numbered every time the
    > router resets, with all the connectivity problems that that implies. If you
    > search google for "BT Dynamic IPv6" you will find many examples of the
    > problems this causes. NAT and DDNS are probably the only way of living with
    > this - or moving to another ISP - which I did. My new ISP uses DHCPv6 PD
    > properly. That is to give you the same prefix (a /48 no less) every time you
    > connect thus avoiding the need for the user to key in a statically assigned
    > IPv6 prefix.

In the BMS that I built, we made no attempt to create IPv6 Prefix pools
locally.  This had been done for IPv4, and some ISPs liked allocating a
subnet to each BMS, and then using routing.  For many ISPs, when running in
an n+1 redundancy mode, they run out of IPs, so they really want a global
pool (on the radius server), and they do ARP or OSPF to arrange routing.

Given lack of scarcity in IPv6 space, and ubiqutiy of permanently on links,
there are no oversubscription reasons, and I can't see a reason not to do all
IPv6 Prefix allocation at sign-up time, and leave it that way.  Even if one
is mandated to "renumber" customers periodically (I'm told this is the case
in some countries), then I'd still do it in the radius database, not the
front-end.

So, I think that the renumbering is the result of IPv4-think.

    > IMHO, ISPs that use dynamic prefix assignments are at least as big a problem
    > as any that might allocate a /128 and are here today rather than in some
    > theoretical future. Perhaps IANA rules could be created here to bar the use
    > of dynamic prefixes and to make this a contractual obligation when an ISP is
    > allocated a prefix.

It would be really nice if your reasons to having switched could be
communicated more loudly.  Maybe this email will help :-)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: [email-masked]
Date: Tue, 10 Nov 2020 11:02:40 +0100

Tony,

> Looking through the large number of posts under  "the race to the bottom" thread, I can't see anyone complaining about the use of short lease IPv6 Prefixes and DHCPv6-PD. So here goes.
> 
> In the UK, the incumbent default ISP (BT) only gives its residential users a dynamic IPv6 prefix. The prefix is allocated whenever the router connects in using DHCPv6 PD and you typically get a different prefix each time. Some routers will ask for the previous prefix to be re-allocated and that request is usually honoured but, in my own experiments, by no means all will do this and, anyway, reset the router and you always get a new prefix.
> 
> The result is that your domestic subnet has to be re-numbered every time the router resets, with all the connectivity problems that that implies. If you search google for "BT Dynamic IPv6" you will find many examples of the problems this causes. NAT and DDNS are probably the only way of living with this - or moving to another ISP - which I did. My new ISP uses DHCPv6 PD properly. That is to give you the same prefix (a /48 no less) every time you connect thus avoiding the need for the user to key in a statically assigned IPv6 prefix.

Yes, IP today is built for for long lived addresses.
Changing IP to deal with ephemeral addressing is an interesting project, but would be a massive undertaking.

Fernando has a draft (slaac-renum) touching on this, but that solution only solves <1% of the problem.

The ISPs wants to diversify their services and push you as a customer to a higher paying tier.
Last time around this track users responded with NAT.

It's not far fetched to think government regulation is required here.

Best regards,
Ole

PS: I might be partly to blame here. When I first implemented DHCPv6 PD in IOS, I wanted a solution contained within the router. We hadn't persistent storage, and given how DUIDs worked I didn't want manual configuration per RR, and ended up doing it as a dynamic pool with no persistent state. In hindsight...