Subject: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability

From: [email-masked]
Date: Mon, 6 Jul 2015 04:47:01 -0700

A new draft has been posted, at http://tools.ietf.org/html/draft-colitti-v6ops-host-addr-availability. Please take a look at it and comment.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 06 Jul 2015 08:33:35 -0400

> A new draft has been posted, at http://tools.ietf.org/html/draft-colitti-v6ops-host-addr-availability. Please take a look at it and comment.

+1000

Simon

---

From: Sander Steffann <[email-masked]>
Date: Mon, 6 Jul 2015 14:46:32 +0200

Hi,

Nice draft, and very much needed. I only have a few comments on 8.2. Address space management:

> In IPv4, all but the world's largest IPv4 networks can be addressed
> using RFC 1918 space.  The total size of net 10 is roughly 2^24 (16
> million) endpoints, with each endpoint receiving one IPv4 address.
> In IPv6, that is equivalent to assigning one /64 per host out of a
> /40.  Under current RIR policies, a /40 is easy to obtain for an
> enterprise network.

I wouldn’t say that a /40 is easy to obtain for enterprise networks. The usual size is a /48. Of course the networks that actually use all of 10/8 would should no problem getting a /40, but that isn’t true for all enterprises.

Suggested new text:

"""
In IPv4, all but the world's largest IPv4 networks can be addressed
using RFC 1918 space.  Many networks can be numbered with e.g.
192.168.0.0/16 which has roughly 2^16 (65536) endpoints, with each
endpoint receiving one IPv4 address. In IPv6, that is equivalent to
assigning one /64 per host out of a /48.  Under current RIR policies,
a /48 is easy to obtain for an enterprise network.

Networks that need a bigger block of RFC 1918 space use 10.0.0.0/8 
which is is roughly 2^24 (16 million) endpoints. The equivalent in
IPv6 would be assigning a /64 per host out of a /40. Enterprises of
such size can easily obtain a /40 under current RIR policies.
"""

or something similar.

> In other words, assigning a single IPv6 /64 per
> host is as feasible as assigning a single IPv4 address per host.
> 
> Currently, residential users receive one IPv4 address and a /56 or
> /60 IPv6 prefix.

I know lots of ISPs that give residential users a /48. I'm afraid this text might suggest giving them small(er) sizes. Maybe change it to:

"""
Currently, residential users often receive one IPv4 address and a /48,
a /56 or even something as tiny as a /60 IPv6 prefix.
"""

Ok, maybe leave the "even something as tiny as" bit out ;)  But that's the message I would like to give to the reader.

> While such networks do not have enough space to
> assign a /64 per device, today such networks almost universally use
> SLAAC.
> 
> Unlike IPv4 where addresses came at a premium, in all these networks,
> there is enough IPv6 address space to supply clients with multiple
> IPv6 addresses.

+1000

Cheers,
Sander

---

From: Andrew Yourtchenko <[email-masked]>
Date: Mon, 6 Jul 2015 23:39:35 +0200

I read the draft and absolutely agree with the spirit. 

Unfortunately, I think it won't work:

As soon as the devices work "good enough" with a single address, appealing to increase the amount of work by administrators in the name of humanity is going to fall on deaf ears.

The only way I see to solve this is to always use SLAAC on the devices: either 'externally' from the prefix received within the RA, or 'internally' from within the prefix received via DHCP-PD, and provide a mandatory registration mechanism for name-to-IP mapping. 

If neither of the above works, as a backup effort the device can try getting N addresses via DHCP IA_NA and release those that it does not need immediately - and displaying a big yellow warning "This network may restrict IPv6 functionality and eat your kittens, contact your system administrator". Because ND is not going to happen on these 'extra' addresses, forwarding wise there will be no impact, just some more DHCP traffic after attachment (the "limited functionality" of course would need just one address and can start immediately).

Those who want tracking can track the upper 64bits or use IA_NA and filter out the addresses that are shortly lived.

Of course to avoid being a religious crusade such an effort need to produce something pragmatic - namely,
 a userland cross-platform API that would allow getting new addresses on demand by application and if needs to - implementing custom transport protocols on top of those on a per-app-per-address basis.

The above conjecture however is even less realistic than politely asking the inconveniences away, so the logical conclusion from that is I fully support this draft.

--a

> On 06 Jul 2015, at 13:47, [email-masked] wrote:
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 7 Jul 2015 00:02:03 +0000

Thanks. One question. Chair hat off.

Section 2 identifies the current deployment model - each interface has a link-local address, a SLAAC address, and one or more temporary addresses. I haven't heard anyone complaining about that. Section 3 goes on to discuss virtual machines/containers, which might each have additional addresses, and the model Facebook is reportedly using, which gives individual addresses to processes. It also mentions draft-herbert-nvo3-ila, which is not a stupid model - I still have some comments on it in a multi-administration environment or for running applications in an "inside" and an "outside" address ("NAT has well-known drawbacks"), but it at least gets rid of the random encapsulations predominant in data centers today.

In other words, we already assign multiple addresses, by some means, to each interface in a network.

You mention SLAAC. Lorenzo mentions that in section 7. He also mentions DHCP address and prefix allocation.

The statement that I don't see in the document, which would help me personally, is a problem statement. I would guess that the problem statement is "we think some networks are limiting host interfaces to a single IPv6 address." I'd want a little more detail, but I'll bet that's the crux of it.

So my question is: "precisely what problem are we solving here?".

> On Jul 6, 2015, at 2:39 PM, Andrew Yourtchenko <[email-masked]> wrote:
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 7 Jul 2015 10:19:16 +0900

On Tue, Jul 7, 2015 at 9:02 AM, Fred Baker (fred) <[email-masked]> wrote:

> The statement that I don't see in the document, which would help me
> personally, is a problem statement. I would guess that the problem
> statement is "we think some networks are limiting host interfaces to a
> single IPv6 address." I'd want a little more detail, but I'll bet that's
> the crux of it.
>

Not necessarily "are limiting" today, but "will limit" in the future.

Suppose that all operating systems of interest to a given network support
DHCPv6 and it is thus possible to run a network without SLAAC and without
IPv4 without denying service to substantial percentages of users.

Let's consider what would happen in such a DHCPv6-only network. How many
addresses would be available to each host? Because DHCPv6 requires an
explicit request to the network before an address can be used, the answer
is, by definition, "as many as the network administrators decide to make
available".

In some of these networks, the "as many as the network administrators
decided to make available" may equate to just one. There could be lots of
reasons for this: technical reasons such as "our IPAM and logging systems
support only one address per host and it's tied into our legal intercept
system so we can only give out one address per host", "we only have enough
TCAM entries for one address per host", "one address per host is what we do
in IPv4, and we want to be consistent with that".

If that sounds unreasonable, now consider what would happen in a hotel
network that charges $5 per device. How many addresses would be available
to hosts on such a network? At best, one for every $5 paid. More likely, if
the billing system does not support more than one IPv6 address (why would
it?), the answer would become "one per MAC address".

I hope we agree that such networks provide suboptimal service, and that
there are a number of things that users would like to do that require
either the availability of more than one IPv6 address.

If we are able to agree on that, then it is a useful statement to make, for
two reasons:
1. The network administrators might listen to the statement.
2. Client and server implementations can implement network configuration
protocols such as DHCPv6 in a way that does not lead to this suboptimal
scenario.

Cheers,
Lorenzo

---

From: Erik Kline <[email-masked]>
Date: Tue, 7 Jul 2015 11:08:46 +0900

Some of this could also serve as input to motivate a SAVI document
defining a basic logging protocol.

I still believe that if there where a trivially deployable logging
methodology that captured

    {IP address, timestamp, rfc7039#section-3.2 binding context}

tuples, or even the full data structure entry described in
rfc6620#section-3.1, then the auditing objectives could be well and
truly met.

I think this is still one large unmet need.  (not necessarily a v6ops
matter, perhaps)

---

From: Yury Shefer <[email-masked]>
Date: Mon, 6 Jul 2015 22:57:09 -0700

Hello authors,

+1 and thanks for the draft!

Since you mentioned 3GPP, maybe it would be useful to mention Broadband
Forum (BBF) as well? BBF End-to-End Architecture technical reports
recommend the following:

1. TR-177 - IPv6 in the context of TR-101 (Nov 2010)
1.1 - Addressing recommendations - paragraph 4.2:
"From  a  routed  RG  perspective,  the  following  IPv6  addresses  may
be  provided  by  the  Service
Provider’s network:
- A /64 prefix for the WAN link GUA (optional, only done in the case of the
numbered WAN
model)
- A  delegated  prefix  for  use  within  the  home  network  (mandatory).
The  Broadband  Forum
suggests  a  size  for  the  delegated  prefix  of  at  least  a  /60  for
home  network  or  SOHO
environments,  with  a  recommended  prefix  length  of  /56.  The
delegated  prefix  may  be
extended to a /48 for larger organizations."

1.2 - IPv6 Prefix Delegation (DHCPv6-PD) - paragraph 4.2.1:
"A different prefix (with a maximum length of 64 bits, and a recommended
length of 56 bits) is
delegated per access loop".

2. TR-187 issue 2 - IPv6 for PPP Broadband Access (Feb 2013)
DHCPv6-PD is a mandatory requirement and it must be supported together with
DHCPv6 /128 WAN address assignment. Here is a few BNG requirements -
chapter 9.1:
"R-22    The BNG, when acting as DHCPv6 Server, MUST be able to assign a
single IPv6 /128
    address to the WAN interface of the RG when using DHCPv6 for address
assignment.
R-23    The  BNG MUST  be  able  to  support  DHCPv6-Prefix  Delegation,
RFC  3633 [16],
    to delegate a prefix to the RG."

On Mon, Jul 6, 2015 at 4:47 AM, <[email-masked]> wrote:

> A new draft has been posted, at
> http://tools.ietf.org/html/draft-colitti-v6ops-host-addr-availability.
> Please take a look at it and comment.
>

-- 
Best regards,
Yury.

---

From: Tore Anderson <[email-masked]>
Date: Tue, 7 Jul 2015 11:08:47 +0200

* [email-masked]

> Please take a look at it and comment.

I read this draft. I strongly agree with its recommendation, and would
support WG adoption.

I have some feedback and suggestions, see below:

1) The abstract and section 6: What exactly is meant by "multiple"?
Would a network conform to the recommendation by allowing 2 global
addresses per host (given the current wording, I think so)? Or should
it be 20? 200? I'd like to see a specific number, or at least a
ballpark number, or failing that some text that explains why no attempt
is being made to quantify what is OK and what is not. (I know this is a
tough one. Sorry..)

2) Section 1.1: Includes the RFC 2119 key words but doesn't appear to
make use o f them anywhere. Maybe s/recommended/RECOMMENDED/ in section
6?

3) Section 2 makes a reference to RFC 6433 section 5.9.4. I think there
must be a typo on the RFC number; RFC6433 doesn't contain a section
5.9.4.

4) In Section 2: «DHCPv6 [RFC7217]». s/7217/3315/, surely?

5) In Section 2: «IPv6 hosts have the ability to configure additional
IPv6 addresses from the on-link prefix without explicit requests to the
network» isn't 100% correct, the hosts need to perform DAD first.
Furthermore, that mechanism could be (ab)used by the network to block
the host from obtaining additional addresses.

6) Nit: In section 3, some of the bullet points terminate with a full
stop, some do not. Looks inconsistent.

7) Section 4: Just like to note that an address-unrestricted network
will still be subject to the first three problems listed thanks to DAD.
(Except DHCPv6-PD.)

8) Section 5: «the problems listed in section without disabling» is
missing a reference to (I assume) section 4.

9) Section 7: «If the prefix is a /64, it can also reshare that prefix
with any downstream clients via [RFC7278] /64 sharing». I think the
reference to RFC7278 is improper. First, RFC7278 is 3GPP specific while
DHCPv6-PD is not. Second, it discusses how to take a /64 that is a link
prefix on an upstream interface and re-use it on a downstream
interface. If you receive a delegated prefix (regardless of what its
length is), that prefix is *not* a link prefix on your upstream
interface and can simply be used on your downstream (or loopback)
interfaces without restrictions. I suggest rewriting something like
this: «The delegated prefix can also be reshared with any downstream
clients, cf. [RFC3633] section 5.»

10) Table 1: Mentions that SLAAC provides "unlimited" addressing. I
think that's a bit of a stretch, given hardware limitations. You can
buy devices today that can only handle a very limited amount IPv6
neighbours (Juniper EX45x0 for example: 1000 NDP entries according to
the datasheet). Given that each node needs at least two addresses
(LLA+GUA), you won't need many nodes with multiple addresses before you
start hitting some hard limitations.

11) Table 1: Might want to say "IA_NA/IA_TA" instead of just "IA_NA".

12) Table 1: The table says DHCPv6 IA_NA gives "unlimited" addressing
while DHCPv6 PD does not. I think maybe it was meant to be the other
way around?

13) Table 1: What's the difference between the rows «Stateful,
request-based» and «Request-based» supposed to be? (You might want to
take into account DAD for SLAAC in one of them, cf. point #4.)

14) Section 7 / Table 1: I think you should discuss whether or not an
approach can be cascaded, or at least easily so. As an example,
consider a 3GPP mobile network. It provides a /64, so it conforms with
the recommendation in this document. However, if you use RFC7278 to
create a tethering wireless network, a tethered host on that network
cannot easily share that network further using because RFC7278 requires
the upstream interface to be a point-to-point one, which the wirel ess
network is not.

15) Section 8.1: «y large enterprise networks, including the enterprise
networks of the authors, are fully dual-stack but do not use or support
DHCPv6.». Not that there's anything wrong with this statement, it left
me wondering: 1) How do you communicate DNS servers to your Windows
hosts, assuming you have any? (Maybe you meant to say «does not use or
support DHCPv6 *address assignment*»?) 2) What happens if you try to
configure a gazillion addresses on your host when connected to this
network? Does it actually work, does the network break, are (some of)
the addresses rendered unusable and if so is it due to simultaneous
addresses per host being limited somehow (hardware or policy) and if so
what is that limitation exactly?

16) Section 8.2: «The total size of net 10 is roughly 2^24». Roughly?
Isn't it *exactly* 2^24?

17) Section 8.2: The reference to RFC1918 should probably be, well, an
(actual) reference.

18) Section 8.2: Echoing what Sander said, a /40 isn't easy to get as
an enterprise (end-user), you'll need something like 128 sites for that
or become your own LIR. I don't think saying you want to assign a /64
per host provides adequate justification for more than the standard /48
per site, at least not in the RIPE region. (But it is of course
possible to do something about that.)

19) Section 8.2: «Currently, residential users receive one IPv4
address» - except that more and more of them are receiving *less than*
one IPv4 address nowadays...

20) Sections 10, 11, A: Text that appears to be from a RFC template is
left over.

Tore

---

From: Ray Hunter <[email-masked]>
Date: Tue, 07 Jul 2015 14:49:15 +0200

Lorenzo Colitti wrote:
> On Tue, Jul 7, 2015 at 9:02 AM, Fred Baker (fred) <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     The statement that I don't see in the document, which would help
>     me personally, is a problem statement. I would guess that the
>     problem statement is "we think some networks are limiting host
>     interfaces to a single IPv6 address." I'd want a little more
>     detail, but I'll bet that's the crux of it.
>
>
> Suppose that all operating systems of interest to a given network 
> support DHCPv6 and it is thus possible to run a network without SLAAC 
> and without IPv4 without denying service to substantial percentages of 
> users.
>
> Let's consider what would happen in such a DHCPv6-only network. How 
> many addresses would be available to each host? Because DHCPv6 
> requires an explicit request to the network before an address can be 
> used, the answer is, by definition, "as many as the network 
> administrators decide to make available".
>
> decided to make available" may equate to just one. There could be lots 
> of reasons for this: technical reasons such as "our IPAM and logging 
> systems support only one address per host and it's tied into our legal 
> intercept system so we can only give out one address per host", "we 
> only have enough TCAM entries for one address per host", "one address 
> per host is what we do in IPv4, and we want to be consistent with that".
>
> network that charges $5 per device. How many addresses would be 
> available to hosts on such a network? At best, one for every $5 paid. 
> More likely, if the billing system does not support more than one IPv6 
> address (why would it?), the answer would become "one per MAC address".
>
> I hope we agree that such networks provide suboptimal service, and 
> that there are a number of things that users would like to do that 
> require either the availability of more than one IPv6 address.
>
> If we are able to agree on that, then it is a useful statement to 
> make, for two reasons:
> 2. Client and server implementations can implement network 
> configuration protocols such as DHCPv6 in a way that does not lead to 
> this suboptimal scenario.
>
> Cheers,
> Lorenzo

If I might add some comment to the "problem statement"

I'd like apps and users to be able to enjoy privacy from the "bad guys", 
and also be shielded from general attack and casual scans.

However, I'd also like the "good guys" to be able to track security 
relationships at some abstract level for audit and security purposes.

IMVHO That's still very much an area of "work to be completed" and is 
also the main reason why network operators want to limit the addresses 
in use (rather than the $5 per address reason cited).

As an example, inbound sessions can be clearly directed to a particular 
stable/well known destination address e.g. using DNS. And application 
daemons can generally be configured to listen only on particular 
addresses. But has anyone tried to force apps to use a particular source 
address as a source for related sessions, or "mirror at L7" outbound 
sessions to use the same source address as the destination address of 
the inbound message?

In OSI speak that's the session layer, and we don't really have one.

So the problem isn't just a matter of supporting multiple addresses at 
the network adapter layer; it's a matter of how those addresses are 
bound to apps, and how/when they are selected.

As one example, I recently came across an app that bound quite happily 
to a particular address on a VM adapter for inbound sessions/messages, 
but defaulted to using the first address configured on the underlying VM 
for all outbound sessions (rendering any stateful firewall pretty much 
useless, because the 1st underlying address was at the mercy of the 
cloud operator, who could shift load around between physical machines at 
will).

As another example, I've also come across plenty of firewalls or proxies 
that use NTLM or some other L7 protocol to identify a "user", but are 
then stuck to IP authentication for further follow up sessions, because 
NTLM or equivalent mechanism is either too slow, or not supported on 
that particular app.

You also have the "https first" problem. In some cases/countries it is 
illegal to intercept/break https encryption (e.g. using fake certs). So 
if a user first connects to a proxy for a site that uses https, there's 
no way of authenticating them, and they are blocked until they use a 
standard http session (to another site).

In short: Is there any intention to include a shim (containing some sort 
of nonce) to allow (legitimate) tracking and authentication (within an AS)?
equivalent of http cookie at the network layer?

That could even be stripped when leaving an AS/site boundary to 
alleviate privacy concerns.

Or at least some more clarification on socket binding?

I fear that this isn't as trivial a problem as the draft seems to suggest.

regards,

---

From: Erik Kline <[email-masked]>
Date: Tue, 7 Jul 2015 21:58:36 +0900

I think it's solvable with the logging I mentioned in an earlier post.

Certainly when Google built such a system internally it seems to have
kept the audit folks happy.

On 7 July 2015 at 21:49, Ray Hunter <[email-masked]> wrote:
>> personally, is a problem statement. I would guess that the problem statement
>> is "we think some networks are limiting host interfaces to a single IPv6
>> address." I'd want a little more detail, but I'll bet that's the crux of it.
>
>
> network that charges $5 per device. How many addresses would be available to
> hosts on such a network? At best, one for every $5 paid. More likely, if the
> billing system does not support more than one IPv6 address (why would it?),
> the answer would become "one per MAC address".
>
> there are a number of things that users would like to do that require either
> the availability of more than one IPv6 address.
>
> I'd like apps and users to be able to enjoy privacy from the "bad guys", and
> also be shielded from general attack and casual scans.
>
> IMVHO That's still very much an area of "work to be completed" and is also
> the main reason why network operators want to limit the addresses in use
> (rather than the $5 per address reason cited).
>
> daemons can generally be configured to listen only on particular addresses.
> But has anyone tried to force apps to use a particular source address as a
> source for related sessions, or "mirror at L7" outbound sessions to use the
> same source address as the destination address of the inbound message?
>
> So the problem isn't just a matter of supporting multiple addresses at the
> network adapter layer; it's a matter of how those addresses are bound to
> apps, and how/when they are selected.
>
> As one example, I recently came across an app that bound quite happily to a
> particular address on a VM adapter for inbound sessions/messages, but
> defaulted to using the first address configured on the underlying VM for all
> outbound sessions (rendering any stateful firewall pretty much useless,
> because the 1st underlying address was at the mercy of the cloud operator,
> who could shift load around between physical machines at will).
>
> that use NTLM or some other L7 protocol to identify a "user", but are then
> stuck to IP authentication for further follow up sessions, because NTLM or
> equivalent mechanism is either too slow, or not supported on that particular
> app.
>
> illegal to intercept/break https encryption (e.g. using fake certs). So if a
> user first connects to a proxy for a site that uses https, there's no way of
> authenticating them, and they are blocked until they use a standard http
> session (to another site).
>
> In short: Is there any intention to include a shim (containing some sort of
> nonce) to allow (legitimate) tracking and authentication (within an AS)?
> That could even be stripped when leaving an AS/site boundary to alleviate
> privacy concerns.
>

---

From: Tore Anderson <[email-masked]>
Date: Tue, 7 Jul 2015 16:21:53 +0200

* Tore Anderson

> I have some feedback and suggestions, see below:

Forgot one:

21) Section 12: Reference [QUIC IETF slides] (from section 5) is
nowhere to be seen.

Tore

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Tue, 7 Jul 2015 17:33:53 +0200

On 7/7/15, Fred Baker (fred) <[email-masked]> wrote:
> Section 2 identifies the current deployment model - each interface has a
> link-local address, a SLAAC address, and one or more temporary addresses. I
> haven't heard anyone complaining about that. Section 3 goes on to discuss
> virtual machines/containers, which might each have additional addresses, and
> the model Facebook is reportedly using, which gives individual addresses to
> processes. It also mentions draft-herbert-nvo3-ila, which is not a stupid
> model - I still have some comments on it in a multi-administration
> environment or for running applications in an "inside" and an "outside"
> address ("NAT has well-known drawbacks"), but it at least gets rid of the
> random encapsulations predominant in data centers today.
>

Lorenzo already commented on the "problem definition" so I will reply
just to this part:

Yes, we both mention them - but I'm arguing the usage of them should
be proactively monitored by the devices themselves. Preferably along
with the tangible benefits provided to the apps when the device is on
a network allowing for more than one address. (Though that is outside
of the "ops" domain).

--a

>> As soon as the devices work "good enough" with a single address, appealing
>> to increase the amount of work by administrators in the name of humanity
>> is going to fall on deaf ears.
>>
>> The only way I see to solve this is to always use SLAAC on the devices:
>> either 'externally' from the prefix received within the RA, or
>> 'internally' from within the prefix received via DHCP-PD, and provide a
>> mandatory registration mechanism for name-to-IP mapping.
>>
>> If neither of the above works, as a backup effort the device can try
>> getting N addresses via DHCP IA_NA and release those that it does not need
>> immediately - and displaying a big yellow warning "This network may
>> restrict IPv6 functionality and eat your kittens, contact your system
>> administrator". Because ND is not going to happen on these 'extra'
>> addresses, forwarding wise there will be no impact, just some more DHCP
>> traffic after attachment (the "limited functionality" of course would need
>> just one address and can start immediately).
>>
>> Those who want tracking can track the upper 64bits or use IA_NA and filter
>> out the addresses that are shortly lived.
>>
>> a userland cross-platform API that would allow getting new addresses on
>> demand by application and if needs to - implementing custom transport
>> protocols on top of those on a per-app-per-address basis.
>>
>> The above conjecture however is even less realistic than politely asking
>> the inconveniences away, so the logical conclusion from that is I fully
>> support this draft.
>>
>> --a
>>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 7 Jul 2015 16:27:53 +0000

Seeing Fred's response, I do agree with him.   My comments are included below.

1. The IPv6 node requirements document does not block any host from using multiple addresses.  So why write a new draft whose abstract says "use multiple addresses for hosts"?  Thus more problem definition is needed in the abstract. 
2. In section 3 and other places in the document, using a /64 die tethering is a hack even if the IETF has an RFC covering the hack.  Use the DHCPv6-PD for tethering. 
3. In section 3, "running virtual machines on hosts" is obvious and falls out from the fact that each virtual machine needs it IPv6 address and mac-address.  This problem does not relate to a host with one mac-address using multiple IPv6 addresses.
4. Section 7.  SLAAC as defined in RFC4862 supports only one IPv6 global address if one prefix is advertised in the RA to the host.  Thus the text in this section can be improved.  If the RA includes multiple prefixes, then the host can generate a global IPv6 address using SLAAC.  
5. Section 8.1.  SAVI for a non-DHCPv6 network also needs a DAD Proxy.  Just add a DAD Proxy to the router and the DAD Proxy programs the dataplane's SAVI.  Also, anywhere the document says DHCPv6 is the only means for admins at universities or corporate deployments to track host sources is questionable.   The router can add DAD Proxy support and then the admin grabs data from the routers DAD proxy for host sources.  I have already made such a statement to v6ops in another thread.  
6.  Please read the IPv6 CE router documents which describer use of an IPv6 loopback address and interface.  Such a loopback interface can serve any app that needs a stable address.

In summary, I have not seen enough of a problem statement nor do I agree with many technical statements in the document to support this version of the document for WG adoption.

Thanks,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 7 Jul 2015 16:51:37 +0000

Perhaps this will help focus the problem statement.

Cable broadband standards for IPv6 already cover multiple IPv6 addresses for hosts.  DSL broadband should also cover multiple IPv6 addresses.   Thus the gross networks one is left with is corporate (includes universities) wired and wireless and cellular.  For IOT and sensors one already has other documents covering their IPv6 behavior.   Additionally, do you want such sensors to also support more than one IPv6 global address?  

Sorry for the typo in my other email related to multiple prefixes in the RA.  It's when multiple prefixes are included in the RA, the host can assign a global address per prefix.  

Thanks,

Hemant

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Jul 2015 08:40:45 +1200

On 08/07/2015 04:27, Hemant Singh (shemant) wrote:
...
> 4. Section 7.  SLAAC as defined in RFC4862 supports only one IPv6 global address if one prefix is advertised in the RA to the host.

It does? I don't see anything in 4862 that prevents a host from generating N separate
IIDs and performing SLAAC N times for the same prefix. Now we are getting rid
of Modified EUI-64 as the default IID, that becomes an obvious thing to do.

    Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 7 Jul 2015 20:48:03 +0000

> On Jul 7, 2015, at 1:40 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Well, yes, but the present algorithm starts from the MAC address on an interface. There's only one such MAC address on any given interface. To do what you said, we need to (see a certain draft) change that algorithm.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Jul 2015 09:08:23 +1200

> Well, yes, but the present algorithm starts from the MAC address on an interface. There's only one such MAC address on any given interface. To do what you said, we need to (see a certain draft) cha…

Agreed. But IMHO we don't need to change 4862, so Hemant's comment is not quite right.

   Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 7 Jul 2015 21:12:26 +0000

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Tuesday, July 07, 2015 4:41 PM
To: Hemant Singh (shemant); Fred Baker (fred); Andrew Yourtchenko
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability

>It does? I don't see anything in 4862 that prevents a host from generating N separate IIDs and performing SLAAC N times for the same prefix. Now we are getting rid of Modified >EUI-64 as the default IID, that becomes an obvious thing to do.

RFC4862 has no guidance for what specific IID to use.  However, RFC4862 does reference RFC4291 in the context of IID and RFC4291 does include the Modified EUI-42 IID format which uses the host's mac-address.   Thanks, Fred, for replying as well.  

I am only discussing RFC4862 with its Modified EUI-64 format for generating a global IPv6 address.  The reason is because section 7 of the colitti document, in the first bullet, speaks of RFC4862.  

Sure, if one deprecates the Modified EUI-64 format and uses, say, privacy extensions, then one prefix can be used by the host to generate multiple IPv6 globals. 

Hemant

---

From: Sander Steffann <[email-masked]>
Date: Wed, 8 Jul 2015 20:17:41 +0200

Hi,

> I think this is still one large unmet need.  (not necessarily a v6ops

I agree. Having such a logging mechanism would take away one of the arguments against SLAAC, which would be a good thing.

Cheers,
Sander

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 8 Jul 2015 18:39:06 +0000

> On Jul 6, 2015, at 7:08 PM, Erik Kline <[email-masked]> wrote:
> 

Operational requirements for such could be a v6ops project, and probably a quick one. You're correct that a protocol development probably belongs in a protocol WG. Calling out the binding anchor makes sense, but some of those (the port on an Ethernet switch to which a host attaches, the security association between a host and the base station on wireless links) don't have obvious portable names (if I say that a given security association is number 27 in the AP's table, that's meaningful to the AP, but I'm not sure it's meaningful to an operator coming in after the fact).

I find myself wondering whether this might get rolled up with some other logging operation, such as for stateful NATs. It begins to sound a lot like a record that associates a set of elements together (a 3-tuple or 5-tuple for a session with a MAC Address and a port number and a time stamp, logged only if the source IP address isn't mapped to the MAC address of interest, perhaps) that is emitted for a reason beyond "it was seen".

Would IPFIX, in some incarnation, address this?

I'll let you write that :-)

---

From: Tom Taylor <[email-masked]>
Date: Wed, 8 Jul 2015 19:10:42 -0400

> I'll let you write that :-)

We have both SYSLOG and IPFIX drafts in progress for NATs. They've been 
held up waiting for the NAT MIB to be finished. (The latter is now in 
the RFCEd Q.) We could look at adding these logs if you want, subject to 
your requirements.

Tom Taylor

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 09 Jul 2015 11:40:31 -0700

Nice draft.. While I agree the (should be obvious to everyone) content 
of this draft I got few nits:

Section 2 mentions on-link prefixes when generating additional 
addresses. There is no reason why this would not apply to off-link 
prefixes as well.

Section 3 points out ePDG as one case, which would benefit from multiple 
addresses. It would be useful here to say that this is about IPsec 
handling/implementation and give a pointer to an appropriate spec 
(TS24.302 I presume).

- Jouni

---

From: Erik Kline <[email-masked]>
Date: Fri, 10 Jul 2015 16:37:47 +0900

On 9 July 2015 at 08:10, Tom Taylor <[email-masked]> wrote:
>> Operational requirements for such could be a v6ops project, and probably a
>> quick one. You're correct that a protocol development probably belongs in a
>> protocol WG. Calling out the binding anchor makes sense, but some of those
>> (the port on an Ethernet switch to which a host attaches, the security
>> association between a host and the base station on wireless links) don't
>> have obvious portable names (if I say that a given security association is
>> number 27 in the AP's table, that's meaningful to the AP, but I'm not sure
>> it's meaningful to an operator coming in after the fact).
>>
>> I find myself wondering whether this might get rolled up with some other
>> logging operation, such as for stateful NATs. It begins to sound a lot like
>> a record that associates a set of elements together (a 3-tuple or 5-tuple
>> for a session with a MAC Address and a port number and a time stamp, logged
>> only if the source IP address isn't mapped to the MAC address of interest,
>> perhaps) that is emitted for a reason beyond "it was seen".
>>
> We have both SYSLOG and IPFIX drafts in progress for NATs. They've been held
> up waiting for the NAT MIB to be finished. (The latter is now in the RFCEd
> Q.) We could look at adding these logs if you want, subject to your
> requirements.

Sounds good to me.  :-)

I think that as long as the format of the binding anchor is extensible
and a minimally useful version is readily available that should
suffice to get started.

I don't know what's normal here: either extensible within an existing
type (i.e. adding fields to a mythical 802Dot11BindingAnchor format)
or extensible by creating new types (i.e.
802Dot11BindingAnchorWithRfc5841PacketMood).

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 15 Jul 2015 17:07:10 +0200

Le 07/07/2015 02:02, Fred Baker (fred) a écrit :
> Section 2 identifies the current deployment model - each interface
> has a link-local address, a SLAAC address, and one or more temporary
> addresses. I haven't heard anyone complaining about that. Section 3
> goes on to discuss virtual machines/containers, which might each have
> additional addresses, and the model Facebook is reportedly using,
> which gives individual addresses to processes. It also mentions
> draft-herbert-nvo3-ila, which is not a stupid model - I still have
> some comments on it in a multi-administration environment or for
> running applications in an "inside" and an "outside" address ("NAT
> has well-known drawbacks"), but it at least gets rid of the random
> encapsulations predominant in data centers today.
>
> You mention SLAAC. Lorenzo mentions that in section 7. He also
> mentions DHCP address and prefix allocation.
>
> statement is "we think some networks are limiting host interfaces to
> a single IPv6 address." I'd want a little more detail, but I'll bet
> that's the crux of it.
>

One problem I see is when operators deliver a single global /64 prefix,
and that /64 is understood as a single IPv6 global address.

Forming multiple IPv6 addresses out of a single /64 is possible for
multiple apps running on that device, so that may not be a problem.
There may be some privacy concerns though, in that an attacker can
identify there is a single device there (the /64 is unique).

But 'sharing' these IPv6 addresses with some other devices (64share) has
more serious drawbacks, typically in the number of subnets - only one
subnet is possible.

(to that, one should add an explanation of why operators deliver a
single /64 to a device - accounting)

Alex

>> As soon as the devices work "good enough" with a single address,
>> appealing to increase the amount of work by administrators in the
>> name of humanity is going to fall on deaf ears.
>>
>> The only way I see to solve this is to always use SLAAC on the
>> devices: either 'externally' from the prefix received within the
>> RA, or 'internally' from within the prefix received via DHCP-PD,
>> and provide a mandatory registration mechanism for name-to-IP
>> mapping.
>>
>> If neither of the above works, as a backup effort the device can
>> try getting N addresses via DHCP IA_NA and release those that it
>> does not need immediately - and displaying a big yellow warning
>> "This network may restrict IPv6 functionality and eat your
>> kittens, contact your system administrator". Because ND is not
>> going to happen on these 'extra' addresses, forwarding wise there
>> will be no impact, just some more DHCP traffic after attachment
>> (the "limited functionality" of course would need just one address
>> and can start immediately).
>>
>> Those who want tracking can track the upper 64bits or use IA_NA
>> and filter out the addresses that are shortly lived.
>>
>> Of course to avoid being a religious crusade such an effort need
>> to produce something pragmatic - namely, a userland cross-platform
>> API that would allow getting new addresses on demand by application
>> and if needs to - implementing custom transport protocols on top
>> of those on a per-app-per-address basis.
>>
>> The above conjecture however is even less realistic than politely
>> asking the inconveniences away, so the logical conclusion from
>> that is I fully support this draft.
>>
>> --a
>>
>>>
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Mukom Akong T." <[email-masked]>
Date: Wed, 15 Jul 2015 21:57:24 +0100

When you read the entire draft, it makes sense and I'd go with the spirit.
And I agree with Fred that the problem statement needs to be more succinct.

Question to Authors:  For addresses that belong to the same interface, is
there a requirement for them to belong to different prefixes?

If not, then for any address gotten from DHCPv6 IA_NA, perhaps a SLAAC
address (or many) can be generated from that prefix. You’d already get
similar behaviour if you used DHCPv6 and configured an IP address from the
same DHCPv6 scope (but in exclude list) statically on the interface towards
the hosts (assuming the default behaviour of some platforms to send our
PIOs in RAs for any addresses manually configured on them).

-- 

Mukom Akong T.

http://about.me/perfexcellence |  twitter: @perfexcellent
------------------------------------------------------------------------------------------------------------------------------------------
“When you work, you are the FLUTE through whose lungs the whispering of the
hours turns to MUSIC" - Kahlil Gibran
-------------------------------------------------------------------------------------------------------------------------------------------

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 19 Jul 2015 11:20:38 +0200 (CEST)

>> A new draft has been posted, at http://tools.ietf.org/html/draft-colitti-v6ops-host-addr-availability. Please take a look at it and comment.

Me too. There are some thing that we need to discuss and some things to 
iron out exact details on, but the document is extremely useful and I 
would like to see it adopted as WG document.

Personally I would like to see (at least) /64 given to each device that it 
can use locally. Having lots of addresses on the same subnet means 
(usually) multicast traffic increases, so the best solution would be to 
just PD /64 (or larger) to each device and let it figure it out.

IPv6 for me is 2^64 networks, not 2^128 addresses, and I would prefer if 
each device got its own /64 for substantial number of deployment 
scenarios, especially when devices are run by different entities which 
includes the ISP (regardless if it's campus network or some other Internet 
service provider).

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ross Chandler <[email-masked]>
Date: Mon, 20 Jul 2015 00:07:28 +0100

> On 19 Jul 2015, at 10:20, Mikael Abrahamsson <[email-masked]> wrote:
> 
> Personally I would like to see (at least) /64 given to each device that it can use locally. Having lots of addresses on the same subnet means (usually) multicast traffic increases, so the best solution would be to just PD /64 (or larger) to each device and let it figure it out.
> 
> IPv6 for me is 2^64 networks, not 2^128 addresses, and I would prefer if each device got its own /64 for substantial number of deployment scenarios, especially when devices are run by different entities which includes the ISP (regardless if it’s campus network or some other Internet service provider).

+1 to this & the draft.

IA_ looks unduly parsimonious. It’s a pity it exists. As the draft illustrates is not adding much if any value over SLAAC.

AFAIK in ISP networks when DHCPv6 /128 WAN addresses are assigned at all they’re in practise coming from a unique /64 per IA.

As the draft notes /64 in 3GPP to every device is a successful interim stage to DHCPv6 PD.

Ross

---

From: Mark Smith <[email-masked]>
Date: Mon, 20 Jul 2015 18:41:41 +1000

Hi,

Firstly, I would support the WG adoption of this draft.

Some thoughts and comments,

Abstract & Intro
~~~~~~~~~~~

I think stating that it also describes benefits would create a bit
more of an interest in reading it e.g.,

"This document recommends that networks provide general-purpose end
   hosts with multiple global addresses, and describes *the benefits
and * options for doing
   so."

3.  Benefits of multiple addresses
~~~~~~~~~~~~~~~~~~~~~~~~

Another benefit :

o  Increased robustness. RFC6724 prefers smaller scope addresses over
larger ones, meaning link-local source and destination addresses are
preferred over ULAs, which are preferred over GAUs. As link-local
addresses can be used by applications [RFC4007], this means that
communications robustness is increased when link-local addresses are
used by applications, because the application can continue to operate
regardless of the presence of one or more routers on the link and
other larger scope addresses. Similarly, when an application is using
ULA addresses, it is robust against events that would disrupt the
network's GUA addressing, such as a GUA renumbering event.

o  Future applications (e.g., per-application IPv6 addresses).

- I think "Transient addressing for related processes: Improved
firewalling by using IPv6 and multiple addresses per host." by Peter
M. Gleitz and Steven M. Bellovin would be an excellent example to
reference:
https://www.cs.columbia.edu/~smb/papers/tarp.pdf

5.  Overcoming limits using Network Address Translation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A reference to RFC2993, "Architectural Implications of NAT", somewhere
would be good.

7.  Options for obtaining more than one address
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"If the prefix is a /64, it can
      also reshare that prefix with any downstream clients via [RFC7278]
      /64 sharing."

I'm not sure RFC7278 should be suggested as a general purpose method,
as there were a number of kludges/limitations in that method specific
to dealing with the lack of DHCPv6-PD support on the 3GPP devices
e.g., switching from a /64 numbered upstream link to a link-local
upstream link (while the carrier device still thinks the /64 is on the
link) so the /64 could be used on the downstream link. Its basically
presenting methods that are a half way between routing and bridging
between the upstream and downstream links, and that created issues
because it wasn't completely one or the other.

8.1.  Stateful addressing and host tracking
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I think it is also worth pointing out that network layer and
link-layer device identifiers/numbers/addresses are not a very
reliable identifier or analogue of people, or more specifically
attackers, because the identifiers/numbers/addresses can change, can
be changed and may not be globally unique, in particularly quite
easily if the attacker is using their own device. Identifying the
individual accessing the network using user/human authentication
methods such as 802.1X and one or more of the what you have, what you
are, or what you know, could provide a audit record of the much
tighter coupling between a human and the network identifiers they use
during the authenticated session.

Nits etc.

2.  Common IPv6 deployment model
~~~~~~~~~~~~~~~~~~~~~~~~~~

There seems to be a reference error here, as RFC6433 is "Requirements
for a Working Group Milestones Tool" and doesn't have a 5.9.4 section.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Jul 2015 19:11:36 +0200

On Tue, Jul 7, 2015 at 7:57 AM, Yury Shefer <[email-masked]> wrote:

> [...]

I looked at TR-177, but I couldn't find a reference to what is supposed to
happen downstream of the residential gateway, so it didn't seem to directly
support the statement in the paragraph that hosts "have the ability to
configure additional IPv6 addresses from the on-link prefix without
explicit requests to the network". Is there a BBF document that has a
statement along those lines somewhere?

---

From: "George, Wes" <[email-masked]>
Date: Sat, 25 Jul 2015 21:21:03 -0400

>identify there is a single device there (the /64 is unique).

WG] that is not a privacy consideration that is unique to this document,
and as such I recommend that we stay away from it, as it just distracts
from the main point by essentially asking for rolling /64 assignments or
multiple /64s. We need to keep the scope of this document fairly tight.

>more serious drawbacks, typically in the number of subnets - only one

WG] I fully expect implementations of the type that this draft discusses
to get by with bridging if they need to share a /64 such as for mobile
device tethering. If they truly need multiple subnets, there is no way to
get around supporting DHCP_PD with some sane configuration around sending
and accepting hints for larger prefixes, because that doesn't work for
SLACC either. That probably needs to be another document, with those
specific use cases documented, because "always support multiple subnets"
is a more significant request than "always support multiple addresses"

Thanks,

Wes

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "George, Wes" <[email-masked]>
Date: Sat, 25 Jul 2015 21:21:02 -0400

I've read -01. I support the part of the draft that explains why multiple
addresses are necessary. The detail around not having to have every
application on a device bound to the same address is quite important and
not at all intuitive to those used to thinking about IPv4 implementations
with only one address available. However, there are some other sections of
this draft that need some refinement to provide better supporting
arguments for the recommendations being given.

Section 3 -
5th bullet "Translation-based.." Need a reference to the 464XLat doc up
here instead of below, specifically a pointer to the section dictating the
use of a separate address

Section 4- This section is pretty handwavey right now. There are plenty of
things in the mobile space that involve waiting for something to happen in
network provisioning. Connecting to the network isn't instantaneous, nor
is enabling tethering. Many times application launches or actions are
delayed by radio wake-up or network congestion, etc. I agree that there is
an maximum window of what constitutes a good user experience, but if I can
have a DHCPv6 server listening for subsequent requests for addresses and
it gets them back to you within a reasonable window for a good user
experience, you need to explain why that won't work. You also need to
explain why if you know that a certain number of addresses are needed, why
a device couldn't request more than one when connecting to the network
initially. I realize mobile isn't the only case here, so we need to have
the same discussion for other types of applications - since instant isn't
a valid answer, because almost nothing is instant on from cold, what's the
outside envelope for a good user experience? Think in terms of initial
connection to the network (where you might ask for multiple addresses) and
then subsequent wakeup where you already have them.
If there's complexity in dealing with failure cases, or uncertainty on
whether a feature is available, explain those issues in more depth. Again,
mobile devices tell users all the time "service not available" or
"restricted by carrier" or whatever. I'm not defending that as a good user
experience, but I'm not certain we can discount solutions based on what we
don't like about how carriers and devices operate today. In other words,
giving a device as many addresses as it wants isn't going to fix all of
those other things that contribute to a bad user experience because they
are restricted by the carrier or impacted by the behavior of the network,
so I don't see solving that issue here as an imperative. I'm open to being
convinced otherwise, but that's something that the draft needs to discuss.

I think you also need to distinguish in the draft between implementations
or situations that REQUIRE more than one address or else they simply won't
work (such as tethering, VMs, etc) vs implementations where it's simply
easier to use multiple addresses than binding the same address to multiple
application sockets such as you would do with a single IPv4 address. If
you're actually doing an IPv4 NAT within the device today to avoid having
to have multiple applications using the same address in IPv4, then make
that clear in the document.

Section 5 - I think we need to cut this section down to a bare minimum or
eliminate it. Waving the NAT boogeyman isn't really the argument to lead
with, unless the authors or other OS manufacturers actually see this as a
credible alternative and are willing to implement it instead of other
options. Otherwise it's just FUD. It's more accurate at this point to say
that NAT doesn't exist for IPv6, because the IETF document is experimental
(IIRC, I'm writing this on a plane and can't check) and no implementations
really exist in the wild, so another solution is required. We've already
written plenty about why NATs are bad elsewhere.

9.1 is combative, dismissive, and incomplete. The problem is not that
operators have made the argument that DHCPv6 is the only way to...
What they've said is that they require a way to track which IPv6 addresses
are assigned to which hosts for policy and legal reasons, and that is
driving a set of deployment decisions. That's not up for debate or
negotiation, and is part of the reason why other discussions of this issue
have been so...vigorous. IETF needs to get out of the habit of telling
operators that their problem isn't a problem, and focus on discussing the
possible solutions, identifying what consensus says is the best way to
solve the problem.
There are several ways to solve the stated problem. One is DHCPv6. It has
pros and cons, some of which are discussed elsewhere in the document,
mainly in the form of why DHCPv6 to assign a single address is a problem.
Another way is whatever the authors are doing on their own networks. I
assume that it also has pros and cons, but since it's not even discussed,
right now you're basically making an unsupported assertion that it's an
alternative. Further, you make no effort to explain how a dual-stack
enterprise network is the same (i.e. It shares this need for tracking) as
the mentioned examples of academic and other networks that provide third
party services. Discuss the alternatives equally instead of trying to
predispose the reader to agree with your pre-conceived belief that DHCPv6
isn't necessary or not the best way to do this because its cons outweigh
its pros. This is where Erik's suggestion about other methods of logging
belongs as well.

Thanks,

Wes

---

From: Mark Smith <[email-masked]>
Date: Sun, 26 Jul 2015 13:25:30 +1000

On 26 July 2015 at 11:21, George, Wes <[email-masked]> wrote:
<snip>
> possible solutions, identifying what consensus says is the best way to

So what I'd like to know more about then is the particular problem
being trying to be solved, or more specifically the business problem
or problems being solved.

"Having a record of IP addresses assigned to devices" isn't a problem
statement, it is a statement of what a mechanism such as DHCP is
theoretically achieves. That record needs to be used for something, so
what are those uses?

I assume it is to satisfy a security need. But what are the specific
security needs? Is there anything formal that requires it, e.g., PCI
DSS?

My view is that one of the security needs is to be able to have an
audit log of devices attached to the network at particular times, so
that if there is a security attack of some form, theoretically it is
possible to identify who and/or who's device was used for the attack.

Both DHCPv4 and DHCPv6 won't actually achieve that goal, because
neither of them record static address assignments on hosts, and DHCPv6
doesn't record link-local addresses assigned or in use either. A
competent attacker will certainly know the risks of using DHCP to
acquire an address on a network they wish to minimise their footprint
on. They'll configure valid static addresses or use link-local
addresses if their target is on-link.

The IETF can come up with a proper solution statement once a proper
problem statement exists. Does a proper problem statement exist
somewhere?

Regards,
Mark.

---

From: "George, Wes" <[email-masked]>
Date: Mon, 27 Jul 2015 09:57:43 -0400

On 7/25/15, 11:25 PM, "Mark Smith" <[email-masked]> wrote:

>> are assigned to which hosts for policy and legal reasons
>
WG] We disagree on whether IETF needs to know what a given implementation
intends to do with the data in order for the problem statement to be
complete.

>security needs? Is there anything formal that requires it, e.g., PCI
WG] Well, I thought that the second part of the statement above was pretty
self-explanatory, but since you asked for more detail, here are a few
examples:

Enforcing/Responding to violations of AUP (spam, malware, attacks,
prohibited content, etc)
Complying with LEA requests (CALEA or equivalent, Lawful Intercept, etc),
DMCA or equivalent takedown requests
Sandboxing devices/users that do not have permission to use the network
due to nonpayment or one of the above violations
Enabling different tiers of service by device or by user, dealing with
entitlement to a given service

>problem statement exists. Does a proper problem statement exist
WG] the problem with the "proper" problem statement you're asking for is
that I don't think the IETF really wants to know the answer because of the
very complex issues it will raise. If the explanation gets much more
detailed than "I have multiple legal and policy enforcement mandates that
require me to have a way to map an IP address/device on the network to the
user that is sending/receiving on it" you start getting into a combination
of legal and policy areas that the IETF typically stays away from. Are we
willing to make tools available for government agencies and businesses to
do things that some of our participants are opposed to? How far are we
willing to go into implementation details that involve multiple
jurisdictions and regions with conflicting views about what is legal,
illegal, and compulsory? It gets difficult to optimize a solution around
that problem space, especially to do it objectively, unless you abstract
it to a fairly high level.
The discussion also tends to devolve quickly into blaming the messenger,
in which people get angry or dismissive to the operators saying that they
need certain functionality, because they are being required by their local
government or employer to do something some consider distasteful with it,
and the operators respond by getting angry at "IETF" for telling them that
the thing that they're legally required to do isn't important or necessary
or is otherwise "wrong". I'd rather stay away from that debate here, but
if you would like to kick the hornets' nest on NANOG again to satisfy your
own curiosity, be my guest.

The only thing I agree might be unclear in my generic problem statement
above is what level of accuracy or confidence in the mapping between IP,
user, and device is necessary, and at what time resolution. In this case,
I think we can point to the systems in place today (e.g. DHCPv4) and say
that it's largely best-effort, with time accuracy on the order of seconds
or minutes, and if something better than that is required, it probably
requires implementation of additional security in address assignment
(SEND, etc).

Wes George

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 27 Jul 2015 15:13:06 +0000

Hi - for a long time now, AERO has been advocating DHCPv6-PD for assigning
a /64 or shorter to a node that can act as either a host or a router. If a router,
the node assigns (portions of) the delegated prefix to one or more downstream
attached links. If a host, the node assigns (portions of) the delegated prefix to a
virtual interface and configures as many addresses from the prefix as it likes on
the virtual interface. The node can then enable host applications that use the
assigned addresses according to the weak end system model. I suppose it is
also possible for the node to act as both a host and a router, if such would
be required according to the use case.

I also agree with what I think I heard Lorenzo saying at the mike, which is that
assigning a /64 or shorter to each node is scalable since even a /32 can support
up to 4B such nodes. That is also consistent with what AERO expects.

Here is a pointer to the AERO draft:

https://datatracker.ietf.org/doc/draft-templin-aerolink/

Thanks in advance for any comments.

Fred
[email-masked]