Subject: Re: [dhcwg] /128 address allocation and "localized IPv6 address space exhaustion", was RE: Brokenness of specs w.r.t. client behavior with M&O bits

From: "H. Peter Anvin" <[email-masked]>
Date: Sat, 01 Nov 2008 17:03:44 -0700

Brian E Carpenter wrote:
> 
>> I would not like to see IPv6 NAPT, but I see that as a real risk if
>> network is using DHCPv6 for allocating hosts just /128 addresses but at
>> the same time is not willing to delegate prefixes on demand. 
> 
> Agreed.

The sad part is that it's probably inevitable given the decision to have 
a fixed address length for IPv6.

	-hpa

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 03 Nov 2008 09:59:03 +1300

On 2008-10-31 21:09, Rémi Denis-Courmont wrote:
> On Fri, 31 Oct 2008 15:31:27 +1300, Brian E Carpenter
> <[email-masked]> wrote:
>>> Well I'm not completely certain whether involving users here would
>>> provide very good experience,
>> I see your argument, but failing silently doesn't seem like a
>> good idea.
> 
> It is only worse. What will actually happen then is, NAPT66.
> 
>>> and certainly operators would not be happy
>>> to see vendors' devices complaining about limitations of their network:)
>> Too bad. This is actually a consumer protection issue;
>> it seems completely appropriate to require that the
>> reason for failure should be notified to the paying user.
> 
> Failing silently or loudly are no options. You cannot blame the operator if
> you expect him to subsidized your device sale. You cannot fail if your
> competitor "just works" by using NAPT66.

Agreed, but you can warn the user that the ISP is offering a defective
service and that you are therefore providing a workaround. There's
no reason to let such an operator off the hook.

    Brian

---

From: "H. Peter Anvin" <[email-masked]>
Date: Sun, 02 Nov 2008 20:09:27 -0800

Mark Smith wrote:
> 
> I'm curious as to why you think this might be the case?
> 
> From what I understand, fixed length addresses were chosen for a few
> reasons (a) only CLNS had variable length addresses, verses every other
> protocol that didn't (e.g. applelalk, IPv4, IPX etc.), so there was
> much more limited experience with variable length addresses, (b)
> people tended to use fixed length CLNS addresses within their
> organisation anyway, to be operationally simpler and (c) it made
> building hardware forwarding ASICS etc. much simpler.
> 
> I can't see why IPv6 having variable length addresses would have
> prevented people creating NAPT66 if /128s were allocated.
> 

Human hoarding instinct combined with old practices from the IPv4 days.
 You can see similar behaviour in areas where the PSTN uses fixed-length
numbers (e.g. North America) versus those there the PSTN uses
variable-length numbers (e.g. Germany).

Yes, people tended to use fixed-length addresses within their
administrative domain, but that is exactly the issue: the crossing of
administrative domains.  With a fixed-length address, each "owner" is
going to try to control the address space as much as possible, even if
it doesn't make sense.  With variable-length addresses, each "owner"
will chop off as much as they feel they need, and knowing they don't
have to worry about it.

	-hpa

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 03 Nov 2008 08:23:51 +0100

On Mon, 03 Nov 2008 09:59:03 +1300, Brian E Carpenter
<[email-masked]> wrote:
>> Failing silently or loudly are no options. You cannot blame the operator
>> if you expect him to subsidized your device sale. You cannot fail if
your
> no reason to let such an operator off the hook.

No, I cannot.

First, if my competitor just "works" silently using NAPT66, _my_ product
will be blamed for the problem, and I have better not print an error
message either.

Second, if I sell my product (subsidized) through the network operator, it
is unlikely that said operator will allow said product to blame its
network. This is quite common for "mobile" devices.

Third, the product might not even be able to print the error message, if it
has no screen, for instance a home router. This is quite common for
broadband fixed access.

Unless the RIR mandate a minimum delegated prefix size in adequate
scenarios, we may have a big problem.

-- 
Rémi Denis-Courmont

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 3 Nov 2008 09:57:14 +0200

>Pardon my ignorance. Is there a concrete case of this in some access
>
>network standard?
>
>(I heard some rumors thereabout)

I have heard rumors as well that were in favor of using DHCPv6 for address allocation also in some cellular accesses. 

By my understanding this is not yet so concrete problem that some other SDO or product would have actually hit this (but those are often driving with rather short lights).

However, the standards allow /128 allocation but I see lack of description how an advanced host should behave in such a situation. Also by my understanding (DS)MIP6, without NEMO, is allocating by default /128 HoA?

The problem could hypothetically occur e.g. when a host is providing IPv6 connectivity for Bluetooth PAN network by using cellular access as WAN (and gets /64 from there), but moves into WLAN coverage (and possibly out of cellular coverage at the same time) and starts to use the WLAN access as WAN but gets only /128 from WLAN... 

In case MIP6 and of just single HoA being available, the host perhaps should use the care-of address (if /64) for providing network connectivity for the local network instead of home address.

Best regards,

	Teemu

---

From: <[email-masked]>
Date: Mon, 3 Nov 2008 10:08:00 +0200

Hi Pekka, 

>-----Original Message-----
>From: ext Pekka Savola [mailto:[email-masked]] 
>Sent: 30 October, 2008 09:26

>But, maybe there is an implementable workaround to this 
>operational issue.  Would it be possible for the host to 
>either 1) run DHCPv6 again, with a different DUID or client 
>identifier (could it get more /128's that way, or 2) use 
>DHCPv6 IAs to request multiple addresses? 
>Then it would proxy these specific addresses instead of a whole /64. 
>If neither of these is possible, how would this scenario be 
>different from the mobile terminal operating as a L2 bridge 
>and multiple devices behind it requesting addresses with DHCPv6?

1-2 could be possibility I guess, but how you can allocate those to
other devices in LAN-side by using SLAAC? 

In case all devices in LAN can do stateful DHCPv6, and operator would
agree on allocating multiple IPv6 addresses for a subscriber, then I
guess the host could indeed act as bridge/DHCPv6 relay. 

Best regards,

	Teemu

---

From: "hyunwook cha" <[email-masked]>
Date: Mon, 3 Nov 2008 17:18:41 +0900

Hello, all.

I would like to share my interests on this issue and discuss DHCPv6
based solution more.
Solutions suggested by Pekka are below.
1) run DHCPv6 again, with a different DUID or client identifier (could
it get more /128's that way,
2) use DHCPv6 IAs to request multiple addresses? Then it would proxy
these specific addresses instead of a whole /64.

IMHO, if we need much closer( = transparent) solution to the SLAAC
plus ND proxy for the Internet sharing of local hosts, the box should
be able to behave as DHCPv6 proxy agent. This means, if the box
receivs Solicit message from a local host, it should be able to
populate a state for message transaction and translate the received
message to a proxyed message in both directions.

I would like to know your opinion about this approach.
Thank you in advance.

Joseph

2008/10/30 Pekka Savola <[email-masked]>:
> On Thu, 30 Oct 2008, [email-masked] wrote:
>>>>
>>>> Consider cellular host case:
>>>> - host implements e.g. ND proxy and DHCPv6 PD for WAN connection
>>>> sharing
>>>> - host attaches to a network where only DHCPv6 happens to be used
>>>> - host gets single /128 IPv6 address from DHCPv6
>>>> - host tries to get some prefixes for its LAN interface with DHCPv6
>>>> PD, but network's policy rejects the prefix request
>
> ...
>>
>> IMHO network that is giving out only /128 to hosts that are providing
>> "network sharing feature" is forcefully creating "localized IPv6 address
>> space exhaustion scenario" for the hosts, which I fear may be tackled
>> with mechanisms familiar from IPv4 address exhaustion scenarios, i.e.
>> with IPv6 NAPT.
>
> FWIW, I agree this would be a problem.
>
> But, maybe there is an implementable workaround to this operational issue.
>  Would it be possible for the host to either 1) run DHCPv6 again, with a
> different DUID or client identifier (could it get more /128's that way, or
> 2) use DHCPv6 IAs to request multiple addresses? Then it would proxy these
> specific addresses instead of a whole /64. If neither of these is possible,
> how would this scenario be different from the mobile terminal operating as a
> L2 bridge and multiple devices behind it requesting addresses with DHCPv6?
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: <[email-masked]>
Date: Mon, 3 Nov 2008 10:29:09 +0200

Hi Joseph, 

>Right as long as DHCPv6 server can assign only one address to the host.
>One more thing I would like to know is whether the host is 
>allowed to configure multiple arbitrary addresses in the 
>scenario of SLAAC plus ND proxy in the service provider's 
>view. If other hosts in LAN configure addresses through SLAAC 
>plus ND proxy, outbound traffics forwarded by the host acting 
>as a gateway have unknown source IPv6 addresses while source 
>MAC address is same. Are there any issues on this point?

The host is allowed to pick whatever IID it wants and also to implement
RFC4941 privacy extensions. 

In 3GPP access the link between host acting as a gateway and access
router is a point-to-point tunneled link, where MAC addresses are not
used. Actually hosts do not necessarily even have MAC address available.

The access router acts just based on prefixes and thus number of
addresses can be configured into simultaneous use from the /64 prefix
host is allocated with.

>Since DHCPv6 server is also able to assign multiple addresses 
>to single client depending on the poliy, the host can activate 
>its server with the assigned address except the one used by 
>itself if it has
>DHCPv6 server installed. Then, other hosts in LAN can 
>configure their addresses through DHCPv6 which might be 
>invoked by proxed RA. Yes, this approach shows more 
>restriction than SLAAC plus ND proxy apparently.

Sounds otherwise feasible approach, but that requires the other hosts to
support DHCPv6, which isn't always the case as DHCPv6 support is not
mandatory, right? At least currently not supported by all IPv6 enabled
hosts.

Best regards,

	Teemu

---

From: Mark Smith <[email-masked]>
Date: Mon, 3 Nov 2008 06:59:24 +1030

Hi Peter,

On Sat, 01 Nov 2008 17:03:44 -0700

Regards,
Mark.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 3 Nov 2008 09:31:29 -0800

> will chop off as much as they feel they need, and knowing they don't

You are looking for technical solutions to an economic tussle. Let's observe first that 64 bits is more than enough to number the entire Internet: 64 bits would allow for 2E15 networks with an HD ratio of 80%. So, any occurrence of  "128 bit allocation" is driven by something else than scarcity, most probably a desire to somehow control the number of devices connected to a particular subscription point.

The case for variable address length, seems to be that "we could build a private network space out of any address allocated by the provider." For example, if the provider allocated a 128 bit address, we could use that address as a prefix in a private network with 160 bit addresses. The argument seems to be that, with variable length address, the providers would not be able to control the private network numbering anymore, even if they wished to. I am afraid that the argument is wrong.

Let's observe first that while there have been many proposal for variable length addresses, the length are always somehow bounded. For example, there will be an address length field in the packet header, and there will be some limited number of bits to encode the length. Even if the length was not technically limited, there will be practical considerations, such as the inefficiencies that accrue when headers are too large. So, if the provider is intent at limiting subscriber capacities, they could always simply allocate a very long address to subscriber, close to the practical maximum. Voila, no private numbering anymore.

But they don't in fact need to go to such length. Providers who want to control user behavior routinely inspect packets in transit. For example, many providers attempt to enforce prohibition against running servers on subscriber connections by filtering incoming TCP SYN packets. If the provider is really intent at enforcing "one address per subscription", they could easily filter incoming packets whose destination address appears longer than the address they allocated.

Economic tussles should be solved by economic arguments. If it is in the economic interest of providers to provide multiple addresses to subscribers, they will indeed do it. Otherwise, the only technical solutions that can succeed against an uncooperative provider are those where a private network is undistinguishable from a single host.

-- Christian Huitema

---

From: "H. Peter Anvin" <[email-masked]>
Date: Mon, 03 Nov 2008 09:39:49 -0800

> Let's observe first that while there have been many proposal for variable length addresses, the length are always somehow bounded. For example, there will be an address length field in the packet h…

This is, of course, true from a technical standpoint, but it doesn't
seem to work out that way in terms of psychology.  Consider, again, the
example of the PSTN, where there is such a limit and it's relatively
small; currently 15 decimal digits.  Very few countries have numbers
that long, but the difference seems to be between countries which have
chosen an all-fixed-format allocation scheme and those that have chosen
a prefix code (variable length) allocation scheme.

If someone is actively trying to prevent suballocation, then, of course,
you're absolutely right.  However, I suspect that most of that is
incompetence rather than malice; hoarding instict combined with "it's
what we always have done."

> Economic tussles should be solved by economic arguments. If it is in the economic interest of providers to provide multiple addresses to subscribers, they will indeed do it. Otherwise, the only tec…

That's a very technologically pure idea, and sometimes it is correct.
However, human behaviour can be changed by changing the parameters
around it, sometimes in nonintuitive ways.

	-hpa

---

From: "hyunwook cha" <[email-masked]>
Date: Tue, 4 Nov 2008 09:22:08 +0900

Hello, Teemu.

Thank you for your clarification.

> mandatory, right? At least currently not supported by all IPv6 enabled

Right. However, you are assuming that provider network is just willing
to give /128 through DHCPv6. It seems that there are no feasible ways
for hosts w/o DHCPv6 clients except 6to6 NAPT about which I do not
want to go further.

Besides this point, above suggestion is not a complete solution
because of the points below.
- DHCPv6 client can not request addresses on behalf of other clients.
If it obtains multiple addresses via multiple IA configurations, all
addresses are just used for the interface on which the client is
running. So, this means that user should remove addresses from the
interface manually and also configure DHCPv6 server with these
addresses manually.
- It is not supported to make both a binding assinged by the remote
server in the provider network and a binding assigned by the local
server in the gateway(the host) consistent because of different
contexts (transactions).

Thus, I would like to suggest DHCPv6 proxy concept to address these
issues. That is, if the gateway acting as a DHCPv6 proxy receivs a
DHCPv6 message from a client on the LAN, it initiates new transaction
for exchanging messages on behalf of the client. Through the proxy,
clients on the LAN can obtain /128 addresses directly from the server
and manage bindings in the server directly while the server sees only
the gateway.

Joseph

  since local hosts in the LAN can not