Subject: [v6ops] draft-ietf-v6ops-host-addr-availability discussion

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 2 Nov 2015 05:15:47 +0000

In the discussion this morning, we wound up in a position that I could not call "consensus", even "rough consensus", but per a hum of those in the room, within shouting distance of achieving that. Several people spoke at the mike asking for a sentence or brief discussion to be added, or a section clarified.

In the interest of expediency, let me ask those who spoke (and anyone else that has an issue) to respond to this note (copying the list) with suggested text. It might be best if this is stated as

OLD TEXT
the text that should be replaced goes here
NEW TEXT
the text that should replace it goes here

or

LOCATION
identify the section the text should go into
PROPOSED TEXT
the text that should be added goes here

I'll permit the authors to declare suggested text out of scope; some of the discussion this morning left them commenting on scope and scope creep. However, I do ask them to justify the exclusion to the list, rather than just ignore the email.

This comment period ends 15 November.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 2 Nov 2015 19:51:06 +0900

Hello,

I do agree with the idea in the draft and I fully support its advancement.

Lorenzo said several times, and the abstract is clear, that the 
recommendation is to not limit the number of addresses are 'provided' to 
general-purposes hosts.  I fully agree with the intent in general.

But because SLAAC is what it is, a network does not 'provide' an address 
to the host.  Worse, it is because of SLAAC universally assumed that the 
end result may look that only one address is provided to the host.

If SLAAC were not what it is, or if it were not that widely adopted, 
then the network could safely assume it 'provided' 2^64 addresses to a 
host when it set a prefixlen 64 in a RA.

For example, the draft says:
>    In most general-purpose IPv6 networks, including all 3GPP networks
>    (see [RFC6459] section 5.2) and Ethernet and Wi-Fi networks using
>    SLAAC [RFC4862], IPv6 hosts have the ability to configure additional
>    IPv6 addresses from the link prefix(es) without explicit requests to
>    the network.

YEs.  But this does not mean that it is good that a 3GPP network gives 
only one /64 to an UE.  This is not a good recommendation.

The right recommendation is the following:

"in a 3GPP network which uses exclusively SLAAC for IPv6 address
  configuration on the UE the network must not limit its ability to set
  multiple distinct IPv6 prefixes in a RA to the UE.  By default there
  should be two."

(other criteria are: in any access network which uses ptp links with 
next-hop as an address rather than a '*' in the forwarding entry for the 
general-purpose host, and exclusively SLAAC)

Also, at the following place:

OLD:
>    Example of how the availability of multiple addresses per host has
>    already allowed substantial deployment of new applications without
>    explicit requests to the network are:
[...]
>    o  /64 sharing [RFC7278].  This was a way to provide IPv6 tethering
>       without needing to wait for network operators to deploy DHCPv6 PD,
>       which is only available in 3GPP release 10.

This is not a good example either.  One wouldn't give an INFORMATIONAL 
document as a recommendation to follow.

I suggest the following NEW:

    An example of how the availability of multiple addresses per host has
    already stimulated successful new applications:
[...]
    o  tethering.  In tethering a UE such as a smartphone connects
       several IP devices on its LAN through the access network and to
       the Internet.  This is realized with DHCPv6-PD [AERO] or some
       other techniques like "/64 sharing" [RFC7278] or other forms of
       bridging.

Alex

Le 02/11/2015 14:15, Fred Baker (fred) a écrit :
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 2 Nov 2015 23:59:04 +0000

I have one text addition suggestion and one question. On P. 7, in Table 1,
suggest adding a new final row as follows:

  requires DAD               Yes                  Yes                   No                 N/A 

Meaning that multi-addresses configured by SLAAC or DHCPv6 IA_NA/IA_TA
must use DAD to check for duplicates on the link they were obtained. In a
multi-addressing environment where millions of addresses are required,
this could amount to a substantial amount of DAD multicast traffic. On the
other hand, DAD is not needed for DHCPv6 PD because the network has
unambiguously delegated the prefix for the node's exclusive use.

I have a question also on table 1. Under ""Unlimited" endpoints", why does
it say "no" for DHCPv6 PD? I think it should say "yes" instead, since a prefix
obtained by DHCPv6 PD can be used to configure an unlimited number of
addresses on the link over which the prefix was received.

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
> Sent: Sunday, November 01, 2015 9:16 PM
> To: [email-masked]
> Subject: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
> 
> In the discussion this morning, we wound up in a position that I could not call "consensus", even "rough consensus", but per a hum of
> those in the room, within shouting distance of achieving that. Several people spoke at the mike asking for a sentence or brief
> discussion to be added, or a section clarified.
> 
> In the interest of expediency, let me ask those who spoke (and anyone else that has an issue) to respond to this note (copying the
> list) with suggested text. It might be best if this is stated as
> 
> OLD TEXT
> I'll permit the authors to declare suggested text out of scope; some of the discussion this morning left them commenting on scope
> and scope creep. However, I do ask them to justify the exclusion to the list, rather than just ignore the email.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 3 Nov 2015 09:28:09 +0900

>  multiple distinct IPv6 prefixes in a RA to the UE.  By default there

On 3GPP there is only one Prefix Information Option in the RA -
http://tools.ietf.org/html/rfc6459#section-5.2 . We can't change that
because the behaviour is defined by 3GPP, not IETF. We might be able to ask
3GPP to change it, but I don't think this document is the place to do that.
3GPP networks already fulfill the spirit of this draft by providing an
entire /64 to each device.

> document as a recommendation to follow.

It's not a recommendation to follow, it's just an example of how having
multiple addresses can allow future applications.

>       other techniques like "/64 sharing" [RFC7278] or other forms of

I'm not sure that tethering is a good example for this section. It's
existed for a long time, so it's not really a new application, and we
already mention it in an earlier section in the draft.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 3 Nov 2015 10:03:50 +0900

> unambiguously delegated the prefix for the node's exclusive use.

I don't think "Requires DAD: No" is correct. Even if the device gets a /64
prefix entirely for its own use, it still needs to do DAD with any other
devices on that /64 (e.g., tethered devices, VMs, etc.).

I'm not opposed to adding a line to the table, though I don't think it
provides much value - if we put our mind to it, I'm sure we could come up
with lots of things we could add to the table that aren't there at the
moment. My main concern is that if we add something to the table it needs
to be correct.

> addresses on the link over which the prefix was received.

The table is written from the perspective of the network assigning
addresses to devices that connect to it. Therefore, it says "no" because if
you use DHCPv6 PD you can't assign address space to an unlimited number of
endpoints - you are limited to however many /64s you have available.

If you use IA_NA or SLAAC, any network with a /64 subnet has, at least in
theory, an "unlimited" number of addresses to assign to clients. Of course,
that's only true in theory. In practice, there's going to be a limit due to
scaling reasons.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 3 Nov 2015 01:24:10 +0000

Hi Lorenzo,

Responses below in “green”:

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Monday, November 02, 2015 5:04 PM
To: Templin, Fred L
Cc: Fred Baker (fred); [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion

On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
I have one text addition suggestion and one question. On P. 7, in Table 1,
suggest adding a new final row as follows:

I don't think "Requires DAD: No" is correct. Even if the device gets a /64 prefix entirely for its own use, it still needs to do DAD with any other devices on that /64 (e.g., tethered devices, VMs, etc.).

I'm not opposed to adding a line to the table, though I don't think it provides much value - if we put our mind to it, I'm sure we could come up with lots of things we could add to the table that aren't there at the moment. My main concern is that if we add something to the table it needs to be correct.

What I mean is “Requires DAD on the interface over which the prefix was received”,
but that was too long to fit in the table. Let’s call the interface “A”. If the node gets
SLAAC addresses or DHCP IA_NA/IA_TA addresses over interface “A”, then it needs
to do DAD on interface “A” for each such address. If the node gets a DHCPv6 PD
over interface “A”, however, it does not need to do DAD over interface “A” at all.

If the node assigns the delegated prefix to interface “B”, then you are right that
that DAD will be required among all tethered devices, VMs, etc. on interface “B”.
But, there will still be no need for DAD on interface “A”. Does that clarify?

The table is written from the perspective of the network assigning addresses to devices that connect to it. Therefore, it says "no" because if you use DHCPv6 PD you can't assign address space to an unlimited number of endpoints - you are limited to however many /64s you have available.

If you use IA_NA or SLAAC, any network with a /64 subnet has, at least in theory, an "unlimited" number of addresses to assign to clients. Of course, that's only true in theory. In practice, there's going to be a limit due to scaling reasons.

I don’t understand this. True that SLAAC and DHCPv6 IA_NA/IA_TA can be used
to assign an unlimited number of addresses to interface “A”. But, so can DHCPv6
PD. When the node receives the delegated prefix (e.g., a /64), it can assign as
many unique IPv6 addresses as it likes to interface “A”. And again, it need not
do DAD for any of them.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 3 Nov 2015 01:31:14 +0000

Bumping up one level – is it clear to everyone that it is OK to assign addresses
taken from a DHCPv6 delegated prefix to the interface over which the prefix
was received? And, that DAD is not required for those addresses?

Thanks - Fred

From: v6ops [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Monday, November 02, 2015 5:24 PM
To: Lorenzo Colitti
Cc: [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion

Hi Lorenzo,

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Monday, November 02, 2015 5:04 PM
To: Templin, Fred L
Cc: Fred Baker (fred); [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Nov 2015 14:46:07 +1300

On 03/11/2015 14:31, Templin, Fred L wrote:
> was received? 

If it was legitimately received, I can't see why it wouldn't be OK.

> And, that DAD is not required for those addresses?

How is that safe? What is to stop a host running SLAAC once it
sees that prefix in an RA, and hitting the same IID by chance?
At least you need to specify that the A bit must not be set.

Come to that, a manual address might collide.

    Brian

---

From: David Farmer <[email-masked]>
Date: Mon, 2 Nov 2015 19:55:39 -0600

> Come to that, a manual address might collide.

And no one has ever screwed up their pseudo-random number generation 
code. :(

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 3 Nov 2015 01:59:03 +0000

Hi Brian,

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, November 02, 2015 5:46 PM
> To: Templin, Fred L; Lorenzo Colitti
> Cc: [email-masked]

OK. When the DHCPv6 server grants a prefix delegation to the client,
the server is asserting that that prefix is unique and is now the sole
property of the client. So, when you say legitimately received I
agree and that is actually a core requirement of DHCPv6 PD.
Otherwise, if the DHCPv6 server gave out duplicate prefixes, the
routing system would become hopelessly corrupted and address
duplication would be the least of our worries.

> At least you need to specify that the A bit must not be set.

I am talking about DAD on interface "A" being the interface over
which the client receives the prefix delegation. No other node on
interface "A" may use the delegated prefix, and no router on
interface "A" may advertise the prefix in an RA. The prefix is the
sole property of the client that received the PD, so the client is
free to assign addresses without needing DAD.

> Come to that, a manual address might collide.

The client itself is the only node that is permitted to assign addresses
from the delegated prefix to an interface, so there is no risk of
collision unless the client itself is somehow corrupt.

Thanks - Fred

> > I don't think "Requires DAD: No" is correct. Even if the device gets a /64 prefix entirely for its own use, it still needs to do DAD with
> any other devices on that /64 (e.g., tethered devices, VMs, etc.).
> >
> > I'm not opposed to adding a line to the table, though I don't think it provides much value - if we put our mind to it, I'm sure we could
> come up with lots of things we could add to the table that aren't there at the moment. My main concern is that if we add something to
> the table it needs to be correct.
> >
> > The table is written from the perspective of the network assigning addresses to devices that connect to it. Therefore, it says "no"
> because if you use DHCPv6 PD you can't assign address space to an unlimited number of endpoints - you are limited to however many
> /64s you have available.
> >
> > If you use IA_NA or SLAAC, any network with a /64 subnet has, at least in theory, an "unlimited" number of addresses to assign to
> clients. Of course, that's only true in theory. In practice, there's going to be a limit due to scaling reasons.
> >

---

From: David Farmer <[email-masked]>
Date: Mon, 2 Nov 2015 20:11:23 -0600

I thought I brought up this issue previously, but I'd like to see 
something addressing excessive use of addresses, maybe adding this as an 
additional paragraph in section 8, recommendations.

    Conversely, it is RECOMMENDED that hosts and applications not
    excessively consume IPv6 addresses, such as generating a new address
    for every connection or with excessive frequency, for instance every
    few minutes or seconds.  A general-purpose host utilizing several
    hundreds or thousands of IPv6 addresses seems excessive and
    unjustified in most situations. This could evoke network operators
    to deploy DHCPv6 simply to apply sanity limits on the number of
    IPv6 addresses available per host.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 3 Nov 2015 02:19:30 +0000

Bumping up again, here is a valid and useful instance of multiaddressing:

1) Client gets a /64 prefix delegation from a DHCPv6 server over interface "A"
2) Client assigns the /64 to a loopback interface
3) Client assigns as many addresses from the /64 as it likes to
    interface "A" (could be millions or more)
4) Client is a pure host (IP forwarding turned off)
5) No DAD needed on any interface

Thanks - Fred

> Sent: Monday, November 02, 2015 5:59 PM
> To: Brian E Carpenter; Lorenzo Colitti
> Cc: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 3 Nov 2015 11:27:32 +0900

> 5) No DAD needed on any interface

Why is the client assigning the addresses to interface A instead of
loopback? There is no need for the client to respond to ND to those
addresses.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 3 Nov 2015 02:35:03 +0000

Hi Lorenzo,

The client assigns the addresses to interface “A” instead of the loopback interface
because otherwise it would have no way of knowing that packets with a source
address taken from the prefix need to go out interface “A”. That is because the
prefix itself is assigned to the loopback interface so addresses need to be
assigned to interface “A” to disassociate them from the loopback interface.

Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Monday, November 02, 2015 6:28 PM
To: Templin, Fred L
Cc: Brian E Carpenter; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion

On Tue, Nov 3, 2015 at 11:19 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Bumping up again, here is a valid and useful instance of multiaddressing:

Why is the client assigning the addresses to interface A instead of loopback? There is no need for the client to respond to ND to those addresses.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 3 Nov 2015 11:35:48 +0900

> But, there will still be no need for DAD on interface “A”. Does that

I didn't need clarification, I already knew what you meant. My point is
that:

   - I don't think we can clarify it without overflowing the space in the
   table cell
   - If we clarify it using text outside the table cell, then that means we
   need to explain the other table rows as well, for consistency.
   - That opens us up to fresh discussions on what text to write in those
   explanations, which could potentially become long and involved.
   - It's not clear to me that the above is worth having this extra row in
   the table.

Thus I'd prefer not to an extra row.

> many unique IPv6 addresses as it likes to interface “A”. And again, it

I think you're confusing unlimited addresses with unlimited endpoints. With
IA_NA or SLAAC, you can number billions of endpoints, each of which might
only have a few addresses. With DHCPv6 PD, you can only number as many
endpoints as you have /64s. Each of those endpoints might be using an
unlimited number of addresses, but there is still a limited number of them.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Nov 2015 15:54:35 +1300

Hi Fred,
> free to assign addresses without needing DAD.

That usage of "may" might confuse some people, so let's pretend
you used a "MUST NOT" construct instead. I could still construct
a host stack that would ignore the issue: its logic would be
"I sent an RS and got no RA/PIO with A=1; but I see traffic from
prefix 2bad:dead:beef::/64, so I'll do SLAAC and DAD in that prefix."

> collision unless the client itself is somehow corrupt.

Or another client on the same LAN gets too clever.

   Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 3 Nov 2015 11:55:58 +0900

Le 03/11/2015 10:31, Templin, Fred L a écrit :
> Bumping up one level – is it clear to everyone that it is OK to
> assign addresses taken from a DHCPv6 delegated prefix to the interface over which the
> prefix was received? And, that DAD is not required for those addresses?

This indeed new enough at least to me.

I agree that if the prefix is delegated for Host with DHCP-PD then it 
has a tighter bind to that Host, tighter than a prefix _advertised_ to 
it with an RA.

In that sense, certainly yes the Host may self-form and assign an 
address on its interface over which the application DHCP-PD received it 
earlier.

And, since the prefix is administratively unique, it would make little 
sense for the Host to DAD that address on that interface.

Moreover, it would bring some advantages for privacy.  Privacy addresses 
as we know them make only the IID variable, while still keeping a 
trackable prefix (the advertised prefix).  With this way of prefix 
delegation, the Host may decide more ways to obfuscate its identity: use 
sometimes the allocated prefix, other times the advertised prefix, in 
some hard-to-detect sequence.

But, if a Host forms an address out of the delegated prefix and wants to 
talk to its Gateway on that interface, maybe it wants to send an RA to 
that Gateway so the Gateway forms an address out of the delegated prefix 
too.  At that point DAD would be needed.

Alex

>
> Thanks - Fred
>
> *From:*v6ops [mailto:[email-masked]] *On Behalf Of *Templin,
> Fred L *Sent:* Monday, November 02, 2015 5:24 PM *To:* Lorenzo
> Colitti *Cc:* [email-masked] *Subject:* Re: [v6ops]
> draft-ietf-v6ops-host-addr-availability discussion
>
> Hi Lorenzo,
>
> *From:*Lorenzo Colitti [mailto:[email-masked]] *Sent:* Monday,
> November 02, 2015 5:04 PM *To:* Templin, Fred L *Cc:* Fred Baker
> (fred); [email-masked] <mailto:[email-masked]> *Subject:* Re: [v6ops]
> draft-ietf-v6ops-host-addr-availability discussion
>
> On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> I have one text addition suggestion and one question. On P. 7, in
> Table 1, suggest adding a new final row as follows:
>
> requires DAD               Yes                  Yes No
> N/A
>
> Meaning that multi-addresses configured by SLAAC or DHCPv6
> IA_NA/IA_TA must use DAD to check for duplicates on the link they
> were obtained. In a multi-addressing environment where millions of
> addresses are required, this could amount to a substantial amount of
> DAD multicast traffic. On the other hand, DAD is not needed for
> DHCPv6 PD because the network has unambiguously delegated the prefix
> for the node's exclusive use.
>
> I don't think "Requires DAD: No" is correct. Even if the device gets
> a /64 prefix entirely for its own use, it still needs to do DAD with
> I'm not opposed to adding a line to the table, though I don't think
> it provides much value - if we put our mind to it, I'm sure we could
> come up with lots of things we could add to the table that aren't
> there at the moment. My main concern is that if we add something to
> I have a question also on table 1. Under ""Unlimited" endpoints", why
> does it say "no" for DHCPv6 PD? I think it should say "yes" instead,
> since a prefix obtained by DHCPv6 PD can be used to configure an
> unlimited number of addresses on the link over which the prefix was
> received.
>
> addresses to devices that connect to it. Therefore, it says "no"
> because if you use DHCPv6 PD you can't assign address space to an
> unlimited number of endpoints - you are limited to however many /64s
> you have available.
>
> If you use IA_NA or SLAAC, any network with a /64 subnet has, at
> least in theory, an "unlimited" number of addresses to assign to
> clients. Of course, that's only true in theory. In practice, there's
> going to be a limit due to scaling reasons.
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 3 Nov 2015 12:03:41 +0900

>> prefix was received? And, that DAD is not required for those addresses?
Is this a statement we need to make in this draft, though?

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 3 Nov 2015 12:05:00 +0900

Le 03/11/2015 09:28, Lorenzo Colitti a écrit :
> On Mon, Nov 2, 2015 at 7:51 PM, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> because the behaviour is defined by 3GPP, not IETF. We might be able to
> ask 3GPP to change it, but I don't think this document is the place to
> do that. 3GPP networks already fulfill the spirit of this draft by
> providing an entire /64 to each device.

I wanted to avoid, but again it loops to me not understanding the spirit 
of the draft.  Maybe it's only me.

Is there any other network that does _not_ provide a /64 to the Host?

>     This is not a good example either.  One wouldn't give an
>     INFORMATIONAL document as a recommendation to follow.
>
>

Sure, tethering was there already, and in the text as well.  All I 
changed is the way the draft mentions tethering, by putting first DHCPv6-PD.

If need is, I can give more text with example of more standard protocols 
based on Mobile IP that achieve the same tethering.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 3 Nov 2015 12:08:04 +0900

> Is there any other network that does _not_ provide a /64 to the Host?

Sure. You can configure a network that only provides addresses via DHCPv6.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 3 Nov 2015 12:13:47 +0900

Le 03/11/2015 12:08, Lorenzo Colitti a écrit :
> On Tue, Nov 3, 2015 at 12:05 PM, Alexandre Petrescu

One can't do that because no default route.

Alex

---

From: David Farmer <[email-masked]>
Date: Mon, 2 Nov 2015 22:24:31 -0600

> On Nov 2, 2015, at 21:13, Alexandre Petrescu <[email-masked]> wrote:
> 

If you set the A=0, M=1 in the RA, a host can only get an address via DHCPv6 and it is not allowed to use SLAAC.  Furthermore, ISC and other DHCPv6 servers allow you to limit the number of addresses a host can have.  I think it is "limit-addrs-per-ia" for ISC, and I think it defaults to 1.

-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 3 Nov 2015 13:38:49 +0900

David,

that statement makes sense, but I'm worried about scope creep. The document
is focused on recommendations to network operators; if we start adding
recommendations to hosts as well, that might well change the scope of the
draft substantially, and might be the start of a process that results in a
large amount of text being added and takes substantial time to complete.

Example: adding that recommendation to the recommendations section might
result in criticism that that recommendation is not adequately
justified/motivated by the rest of the draft's text. The response to that
criticism might be to add text to the draft to motivate it, but that text
would obviously need to go through the WG, we'd have to gain consensus on
it, etc.

Also, on the text itself: if a host is given an IPv6 prefix via DHCPv6 PD,
I don't know if it's "excessive and unjustified" for it to decide, for
example, to use a different IPv6 address for each server it talks to. The
extra load on the network might well be nil.

Cheers,
Lorenzo

On Tue, Nov 3, 2015 at 11:11 AM, David Farmer <[email-masked]> wrote:

>> In the discussion this morning, we wound up in a position that I could
>> not call "consensus", even "rough consensus", but per a hum of those in the
>> room, within shouting distance of achieving that. Several people spoke at
>> the mike asking for a sentence or brief discussion to be added, or a
>> section clarified.
>>
>> In the interest of expediency, let me ask those who spoke (and anyone
>> else that has an issue) to respond to this note (copying the list) with
>> suggested text. It might be best if this is stated as
>>
>> OLD TEXT
>> I'll permit the authors to declare suggested text out of scope; some of
>> the discussion this morning left them commenting on scope and scope creep.
>> However, I do ask them to justify the exclusion to the list, rather than
>> just ignore the email.
>>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 3 Nov 2015 07:02:05 +0000

Hi Lorenzo,

From: Lorenzo Colitti [mailto:[email-masked]] 
Sent: Monday, November 02, 2015 6:36 PM
To: Templin, Fred L
Cc: Fred Baker (fred); [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion

On Tue, Nov 3, 2015 at 10:24 AM, Templin, Fred L <[email-masked]> wrote:
I don't think "Requires DAD: No" is correct. Even if the device gets a /64 prefix entirely for its own use, it still needs to do DAD with any other devices on that /64 (e.g., tethered devices, VMs, etc.).

 

I didn't need clarification, I already knew what you meant. My point is that:
• I don't think we can clarify it without overflowing the space in the table cell
• If we clarify it using text outside the table cell, then that means we need to explain the other table rows as well, for consistency.
• That opens us up to fresh discussions on what text to write in those explanations, which could potentially become long and involved.
• It's not clear to me that the above is worth having this extra row in the table.
Thus I'd prefer not to an extra row.

FLT >>> It seems to me you did need clarification, and yes DAD avoidance is a
FTL >>> big deal worth noting in the table.

FLT>>> But, there are billions of /64s available even in just a /32. If you want to
FLT>>> delegate /64s to billions of nodes, just use DHCPv6 PD.

FLT>>> Scaling limits apply to the number of nodes that can be accommodated
FLT>>> on a link that is serviced by SLAAC and/or DHCPv6 IA_NA/IA_TA, yes.
FLT>>> It is probably a research question as to whether the scaling limits for
FLT>>> DHCPv6 PD are more or less pressing than the scaling limits for
FLT>>> SLAAC/DHCPv6 IA_NA/IA_TA. The line in your table is therefore
FLT>>> meaningless and could be removed.

I think you're confusing unlimited addresses with unlimited endpoints. With IA_NA or SLAAC, you can number billions of endpoints, each of which might only have a few addresses. With DHCPv6 PD, you can only number as many endpoints as you have /64s. Each of those endpoints might be using an unlimited number of addresses, but there is still a limited number of them.

FLT>>> Again, the scaling question comes to whether a single link can accommodate
FLT>>> more endpoints using SLAAC/DHCPv6 IA_NA/IA_TA or DHCPv6 PD if the
FLT>>> number of eligible /64s numbers in the billions.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 3 Nov 2015 07:10:51 +0000

Hi Brian,

> Sent: Monday, November 02, 2015 6:55 PM

The malicious (or otherwise broken) host 'A' could configure any number
of addresses it likes, but it would do so in a vacuum because ingress
filtering will prevent a packet with a source address from a prefix
belonging to host B from being accepted. So, node B has no reason
to fear address duplication by node A.

Also, what if node B in fact did do DAD and A heard it? What is to stop
A from configuring a duplicate address and trying to use it just to mess
up the legitimate operation of node B?

What you are describing is a broken implementation that could only
be employed by a malicious host, and not something that honors
the standards. Doing DAD is not going to guard against malicious
hosts.

Thanks - Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 3 Nov 2015 07:13:40 +0000

Hi Alex,

> From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Monday, November 02, 2015 6:56 PM
> To: [email-masked]
> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD
> 
> 
> 
> > Bumping up one level - is it clear to everyone that it is OK to

"Host sends an RA to the Gateway" doesn't make any sense that
I am aware of.

Thanks - Fred

> > Responses below in "green":
> >
> > What I mean is "Requires DAD on the interface over which the prefix
> > was received",
> >
> > but that was too long to fit in the table. Let's call the interface
> > "A". If the node gets
> >
> > SLAAC addresses or DHCP IA_NA/IA_TA addresses over interface "A",
> > then it needs
> >
> > to do DAD on interface "A" for each such address. If the node gets a
> >  DHCPv6 PD
> >
> > over interface "A", however, it does not need to do DAD over
> > interface "A" at all.
> >
> > If the node assigns the delegated prefix to interface "B", then you
> > are right that
> >
> > that DAD will be required among all tethered devices, VMs, etc. on
> > interface "B".
> >
> > But, there will still be no need for DAD on interface "A". Does that
> >  clarify?
> >
> > I don't understand this. True that SLAAC and DHCPv6 IA_NA/IA_TA can
> > be used
> >
> > to assign an unlimited number of addresses to interface "A". But, so
> > can DHCPv6
> >
> > many unique IPv6 addresses as it likes to interface "A". And again,
> > it need not
> >
> > do DAD for any of them.
> >
> >
> >

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 3 Nov 2015 07:15:38 +0000

Hi Lorenzo,

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Monday, November 02, 2015 7:04 PM
To: Alexandre Petrescu
Cc: [email-masked] WG
Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD

On Tue, Nov 3, 2015 at 11:55 AM, Alexandre Petrescu <[email-masked]<mailto:[email-masked]>> wrote:

FLT>>> I think so. An opportunity for DAD avoidance when we are talking about
FLT>>> configuring huge numbers of addresses seems like a significant advantage.

---

From: David Farmer <[email-masked]>
Date: Tue, 3 Nov 2015 01:40:13 -0600

On 11/2/15 22:38 , Lorenzo Colitti wrote:
> David,
>
> that statement makes sense, but I'm worried about scope creep. The
> document is focused on recommendations to network operators; if we start
> adding recommendations to hosts as well, that might well change the
> scope of the draft substantially, and might be the start of a process
> that results in a large amount of text being added and takes substantial
> time to complete.

I'm sensitive to the scope creep issue.  However, you are asking network 
operators to take all the risk and to change they way they do things. 
Yes, it's old IPv4 thinking and we have to find the new normal for IPv6. 
  But, a little balance asking hosts and applications to not break the 
networks if the network operates open things up would be some 
good-faith.

I'm asking for a little bit of a social contract here, basically the 
deal is I won't nail down all the 2x4s if you promise not to pick them 
up and beat me over the head with them.  But, if your not even willing 
to tell me you won't beat me over the head with the 2x4s, why would I 
ever not nail them all down.

> justified/motivated by the rest of the draft's text. The response to
> that criticism might be to add text to the draft to motivate it, but
> that text would obviously need to go through the WG, we'd have to gain
> consensus on it, etc.
>
> Also, on the text itself: if a host is given an IPv6 prefix via DHCPv6
> PD, I don't know if it's "excessive and unjustified" for it to decide,
> for example, to use a different IPv6 address for each server it talks
> to. The extra load on the network might well be nil.

I'm not stuck on those words, I'm just looking for something that 
acknowledges if networks impose no hard limit on the number of IPv6 
addresses, that is not a excuse for hosts and applications to go crazy.

Furthermore, I'm a little worried if I set a threshold of lets say 1000 
IPv6 addresses and then quarantine a host as a network abuser, am I 
violating the spirit of this draft? Is 500 too low? 250?

Maybe you can think of a different way to cover this.

Thanks

> Cheers,
> Lorenzo
>
> On Tue, Nov 3, 2015 at 11:11 AM, David Farmer <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     something addressing excessive use of addresses, maybe adding this
>     as an additional paragraph in section 8, recommendations.
>
>         In the discussion this morning, we wound up in a position that I
>         could not call "consensus", even "rough consensus", but per a
>         hum of those in the room, within shouting distance of achieving
>         that. Several people spoke at the mike asking for a sentence or
>         brief discussion to be added, or a section clarified.
>
>         In the interest of expediency, let me ask those who spoke (and
>         anyone else that has an issue) to respond to this note (copying
>         the list) with suggested text. It might be best if this is stated as
>
>         OLD TEXT
>         I'll permit the authors to declare suggested text out of scope;
>         some of the discussion this morning left them commenting on
>         scope and scope creep. However, I do ask them to justify the
>         exclusion to the list, rather than just ignore the email.
>
>         [email-masked] <mailto:[email-masked]>
>     David Farmer               Email: [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 3 Nov 2015 17:02:02 +0900

> violating the spirit of this draft? Is 500 too low? 250?

I think this concern can be addressed without placing requirements on the
host and thus host creep. For example, would it address your concerns if
the draft said that a network can pose limits on IPv6 addresses if the
device uses an unreasonable number of addresses (e.g., hundreds)?

---

From: David Farmer <[email-masked]>
Date: Tue, 3 Nov 2015 03:14:35 -0600

On 11/3/15 02:02 , Lorenzo Colitti wrote:
> On Tue, Nov 3, 2015 at 4:40 PM, David Farmer <[email-masked]
>     Furthermore, I'm a little worried if I set a threshold of lets say
>     1000 IPv6 addresses and then quarantine a host as a network abuser,
>     am I violating the spirit of this draft? Is 500 too low? 250?
>
>
> I think this concern can be addressed without placing requirements on
> the host and thus host creep. For example, would it address your
> concerns if the draft said that a network can pose limits on IPv6
> addresses if the device uses an unreasonable number of addresses (e.g.,
> hundreds)?

Something like that will probably work.  Where are you thinking of 
putting it?

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 3 Nov 2015 18:24:32 +0900

Le 03/11/2015 16:13, Templin, Fred L a écrit :
> Hi Alex,
>
>> -----Original Message----- From: v6ops
>> [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
>> Sent: Monday, November 02, 2015 6:56 PM To: [email-masked] Subject:
>> Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion -
>> address out of the delegated prefix, on the egress - no DAD
>>
>>
>>
>>> assign addresses taken from a DHCPv6 delegated prefix to the
>>> interface over which the prefix was received? And, that DAD is
>>> not required for those addresses?
>>
>> I agree that if the prefix is delegated for Host with DHCP-PD then
>> it has a tighter bind to that Host, tighter than a prefix
>> _advertised_ to it with an RA.
>>
>> address on its interface over which the application DHCP-PD
>> received it earlier.
>>
>> And, since the prefix is administratively unique, it would make
>> little sense for the Host to DAD that address on that interface.
>>
>> Moreover, it would bring some advantages for privacy.  Privacy
>> addresses as we know them make only the IID variable, while still
>> keeping a trackable prefix (the advertised prefix).  With this way
>> of prefix delegation, the Host may decide more ways to obfuscate
>> its identity: use sometimes the allocated prefix, other times the
>> advertised prefix, in some hard-to-detect sequence.
>>
>> But, if a Host forms an address out of the delegated prefix and
>> wants to talk to its Gateway on that interface, maybe it wants to
>> send an RA to that Gateway so the Gateway forms an address out of
>> the delegated prefix too.  At that point DAD would be needed.
>
> "Host sends an RA to the Gateway" doesn't make any sense that I am
> aware of.

I should have said "to the link on which the Gateway is present".

On a shared link, where each such Host is delegated a prefix (no prefix 
advertised by the RA from the gateway), these Hosts will want to reach 
each other directly w/o being ICMP Redirected by the Gateway.  Which 
address should such a Host use to reach its neighbor.

Alex

>
> Thanks - Fred
>
>>
>> Alex
>>
>>>
>>> Thanks - Fred
>>>
>>> *From:*v6ops [mailto:[email-masked]] *On Behalf Of
>>> *Templin, Fred L *Sent:* Monday, November 02, 2015 5:24 PM *To:*
>>> Lorenzo Colitti *Cc:* [email-masked] *Subject:* Re: [v6ops]
>>> *From:*Lorenzo Colitti [mailto:[email-masked]] *Sent:*
>>> Monday, November 02, 2015 5:04 PM *To:* Templin, Fred L *Cc:*
>>> Fred Baker (fred); [email-masked] <mailto:[email-masked]>
>>> *Subject:* Re: [v6ops] draft-ietf-v6ops-host-addr-availability
>>> discussion
>>>
>>> I have one text addition suggestion and one question. On P. 7,
>>> in Table 1, suggest adding a new final row as follows:
>>>
>>> IA_NA/IA_TA must use DAD to check for duplicates on the link
>>> they were obtained. In a multi-addressing environment where
>>> millions of addresses are required, this could amount to a
>>> substantial amount of DAD multicast traffic. On the other hand,
>>> DAD is not needed for DHCPv6 PD because the network has
>>> I don't think "Requires DAD: No" is correct. Even if the device
>>> gets a /64 prefix entirely for its own use, it still needs to do
>>> DAD with any other devices on that /64 (e.g., tethered devices,
>>> VMs, etc.).
>>>
>>> I'm not opposed to adding a line to the table, though I don't
>>> think it provides much value - if we put our mind to it, I'm sure
>>> we could come up with lots of things we could add to the table
>>> that aren't there at the moment. My main concern is that if we
>>> add something to the table it needs to be correct.
>>>
>>> What I mean is "Requires DAD on the interface over which the
>>> prefix was received",
>>>
>>> but that was too long to fit in the table. Let's call the
>>> interface "A". If the node gets
>>>
>>> SLAAC addresses or DHCP IA_NA/IA_TA addresses over interface
>>> "A", then it needs
>>>
>>> to do DAD on interface "A" for each such address. If the node
>>> gets a DHCPv6 PD
>>>
>>> If the node assigns the delegated prefix to interface "B", then
>>> you are right that
>>>
>>> that DAD will be required among all tethered devices, VMs, etc.
>>> on interface "B".
>>>
>>> But, there will still be no need for DAD on interface "A". Does
>>> that clarify?
>>>
>>> I have a question also on table 1. Under ""Unlimited" endpoints",
>>> why does it say "no" for DHCPv6 PD? I think it should say "yes"
>>> instead, since a prefix obtained by DHCPv6 PD can be used to
>>> configure an unlimited number of addresses on the link over which
>>> the prefix was received.
>>>
>>> The table is written from the perspective of the network
>>> assigning addresses to devices that connect to it. Therefore, it
>>> says "no" because if you use DHCPv6 PD you can't assign address
>>> space to an unlimited number of endpoints - you are limited to
>>> however many /64s you have available.
>>>
>>> clients. Of course, that's only true in theory. In practice,
>>> there's going to be a limit due to scaling reasons.
>>>
>>> I don't understand this. True that SLAAC and DHCPv6 IA_NA/IA_TA
>>> can be used
>>>
>>> to assign an unlimited number of addresses to interface "A". But,
>>> so can DHCPv6
>>>
>>> many unique IPv6 addresses as it likes to interface "A". And
>>> again, it need not
>>>
>>> do DAD for any of them.
>>>
>>>
>>>
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 3 Nov 2015 10:05:22 +0000

Hi Alex,

> From: Alexandre Petrescu [mailto:[email-masked]]
> Sent: Tuesday, November 03, 2015 1:25 AM
> To: Templin, Fred L; [email-masked]

Each host will initially have only a default route pointing to a router on
the shared link and no on-link prefix. For host-to-host communications
on the link, there would need to be a redirect. Is that bad?

Thanks - Fred

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 3 Nov 2015 20:46:06 +0900

Hi Fred,

Le 03/11/2015 19:05, Templin, Fred L a écrit :
> Hi Alex,
>
>> -----Original Message----- From: Alexandre Petrescu
>> [mailto:[email-masked]] Sent: Tuesday, November 03,
>> 2015 1:25 AM To: Templin, Fred L; [email-masked] Subject: Re:
>> [v6ops] draft-ietf-v6ops-host-addr-availability discussion -
>>>> [mailto:[email-masked]] On Behalf Of Alexandre
>>>> Petrescu Sent: Monday, November 02, 2015 6:56 PM To:
>>>> [email-masked] Subject: Re: [v6ops]
>>>> draft-ietf-v6ops-host-addr-availability discussion - address
>>>> out of the delegated prefix, on the egress - no DAD
>>>>
>>>>
>>>>
>>>>> Bumping up one level - is it clear to everyone that it is OK
>>>>> to assign addresses taken from a DHCPv6 delegated prefix to
>>>>> the interface over which the prefix was received? And, that
>>>>> DAD is not required for those addresses?
>>>>
>>>> I agree that if the prefix is delegated for Host with DHCP-PD
>>>> then it has a tighter bind to that Host, tighter than a prefix
>>>> In that sense, certainly yes the Host may self-form and assign
>>>> an address on its interface over which the application DHCP-PD
>>>> received it earlier.
>>>>
>>>> And, since the prefix is administratively unique, it would
>>>> make little sense for the Host to DAD that address on that
>>>> interface.
>>>>
>>>> addresses as we know them make only the IID variable, while
>>>> still keeping a trackable prefix (the advertised prefix).  With
>>>> this way of prefix delegation, the Host may decide more ways to
>>>> obfuscate its identity: use sometimes the allocated prefix,
>>>> other times the advertised prefix, in some hard-to-detect
>>>> sequence.
>>>>
>>>> But, if a Host forms an address out of the delegated prefix
>>>> and wants to talk to its Gateway on that interface, maybe it
>>>> wants to send an RA to that Gateway so the Gateway forms an
>>>> address out of the delegated prefix too.  At that point DAD
>>>> would be needed.
>>>
>>> "Host sends an RA to the Gateway" doesn't make any sense that I
>>> am aware of.
>>
>> On a shared link, where each such Host is delegated a prefix (no
>> prefix advertised by the RA from the gateway), these Hosts will
>> want to reach each other directly w/o being ICMP Redirected by the
>> Gateway.  Which address should such a Host use to reach its
>> neighbor.
>
> Each host will initially have only a default route pointing to a
> router on the shared link and no on-link prefix. For host-to-host
> communications on the link, there would need to be a redirect. Is
> that bad?

I think it can work with defroute and no onlink prefix.

Whether or not is bad can be a matter of number of such redirects.
Intuitively, it can be very few Redirects if a few Hosts, and it can be
many Redirects if the Hosts are tethering devices; because each active
address behind device would need to be be re-directed.

But yes the DAD-less aspect of addresses self-formed out of DHCP-PD'ed
prefixes looks good.

Alex

>>>>> *Templin, Fred L *Sent:* Monday, November 02, 2015 5:24 PM
>>>>> *To:* Lorenzo Colitti *Cc:* [email-masked] *Subject:* Re:
>>>>> [v6ops] draft-ietf-v6ops-host-addr-availability discussion
>>>>>
>>>>> Hi Lorenzo,
>>>>>
>>>>> Monday, November 02, 2015 5:04 PM *To:* Templin, Fred L
>>>>> *Cc:* Fred Baker (fred); [email-masked]
>>>>> <mailto:[email-masked]> *Subject:* Re: [v6ops]
>>>>> <[email-masked]
>>>>> <mailto:[email-masked]>> wrote:
>>>>>
>>>>> I have one text addition suggestion and one question. On P.
>>>>> 7, in Table 1, suggest adding a new final row as follows:
>>>>>
>>>>> substantial amount of DAD multicast traffic. On the other
>>>>> hand, DAD is not needed for DHCPv6 PD because the network
>>>>> has unambiguously delegated the prefix for the node's
>>>>> exclusive use.
>>>>>
>>>>> I don't think "Requires DAD: No" is correct. Even if the
>>>>> device gets a /64 prefix entirely for its own use, it still
>>>>> needs to do DAD with any other devices on that /64 (e.g.,
>>>>> tethered devices, VMs, etc.).
>>>>>
>>>>> I'm not opposed to adding a line to the table, though I
>>>>> don't think it provides much value - if we put our mind to
>>>>> it, I'm sure we could come up with lots of things we could
>>>>> add to the table that aren't there at the moment. My main
>>>>> concern is that if we add something to the table it needs to
>>>>> be correct.
>>>>>
>>>>> to do DAD on interface "A" for each such address. If the
>>>>> node gets a DHCPv6 PD
>>>>>
>>>>> If the node assigns the delegated prefix to interface "B",
>>>>> then you are right that
>>>>>
>>>>> that DAD will be required among all tethered devices, VMs,
>>>>> etc. on interface "B".
>>>>>
>>>>> But, there will still be no need for DAD on interface "A".
>>>>> Does that clarify?
>>>>>
>>>>> I have a question also on table 1. Under ""Unlimited"
>>>>> endpoints", why does it say "no" for DHCPv6 PD? I think it
>>>>> should say "yes" instead, since a prefix obtained by DHCPv6
>>>>> PD can be used to configure an unlimited number of addresses
>>>>> on the link over which the prefix was received.
>>>>>
>>>>> assigning addresses to devices that connect to it. Therefore,
>>>>> it says "no" because if you use DHCPv6 PD you can't assign
>>>>> address space to an unlimited number of endpoints - you are
>>>>> limited to however many /64s you have available.
>>>>>
>>>>> If you use IA_NA or SLAAC, any network with a /64 subnet has,
>>>>> at least in theory, an "unlimited" number of addresses to
>>>>> assign to clients. Of course, that's only true in theory. In
>>>>> practice, there's going to be a limit due to scaling
>>>>> reasons.
>>>>>
>>>>> I don't understand this. True that SLAAC and DHCPv6
>>>>> IA_NA/IA_TA can be used
>>>>>
>>>>> to assign an unlimited number of addresses to interface "A".
>>>>> But, so can DHCPv6
>>>>>
>>>>> _______________________________________________ v6ops
>>>>> mailing list [email-masked]
>>>> list [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 3 Nov 2015 12:08:52 +0000

Hi Alex,

> Sent: Tuesday, November 03, 2015 3:46 AM
> To: Templin, Fred L
> Cc: [email-masked]

OK.

> address behind device would need to be be re-directed.

This is why AERO specifies a "prefix redirect" capability where the redirect
covers not just a singleton address but the entire delegated prefix. It is
currently specified for tunnels, but can also be adapted for ordinary links.
RFC6706 is where the prefix redirect was originally specified, and carries
over into AERO(bis).

> But yes the DAD-less aspect of addresses self-formed out of DHCP-PD'ed

OK.

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 4 Nov 2015 10:47:25 +1300

Hello Fred,

> to fear address duplication by node A.

I'm not sure how an ingress filter somewhere upstream would know that
the packet came from the "wrong" host. But I don't think that's enough;
a duplicate address on the LAN is already a problem in itself.

> up the legitimate operation of node B?

Nothing. That, I think, is why the RFCs make DAD mandatory.

> the standards. 

I don't think it's malicious; it's just trying to get IPv6 connectivity
in the face of what it sees as a broken router that isn't responding
to RS. But that isn't really my point - my point is that whatever we
do, it's impossible to assert that a duplicate address will never arise.

> Doing DAD is not going to guard against malicious
> hosts.

No, but it might allow you to detect the resulting anomaly.

   Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 3 Nov 2015 22:37:02 +0000

Hi Brian,

> Sent: Tuesday, November 03, 2015 1:47 PM
> Subject: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
> 
> Hello Fred,
> 

Actually, the simpler answer to your question is that the node would
act as a host internally, but appear to be a router on the link from an
outside observer's perspective. And, routers do not do DAD for the
source addresses of packets that pass through them.

Thanks - Fred

---

From: Philip Homburg <[email-masked]>
Date: Wed, 04 Nov 2015 00:06:53 +0100

> Nothing. That, I think, is why the RFCs make DAD mandatory.

There are a few things something I don't understand in this discussion.

Suppose we have a router with one upstream ethernet interface and a
couple of downstream interfaces.

The upstream interface does not have any addresses assigned other than
link local. The router receives a prefix through DHCPv6 and assigns
a number of /64 prefixes to the downstream interfaces.

Two things should be obvious:
- the router is not going to perform DAD on addresses used by hosts on 
  its downstream interfaces
- other routers on the upstream interface are not going to use ND on
  addresses covered by the prefix, they will use the link local address
  of the router instead.

No we replace the router by a host. The host receives a prefix using DHCPv6 PD
and starts using it. Why would the host perform DAD on addresses covered
by the delegated prefix when a router would not do this?
Why would routers try to perform ND on addresses covered by the prefix 
instead sending traffic to the link local address?

There might be a problem though. Routers take part in a routing protocol.
So it should be obvious to all routers how to forward traffic to a
delegated prefix.

When prefix delegation happens over a point-to-point link then, 'the other
side' is also clearly defined. So a host could receive a prefix and it
would work.

In the case of ethernet, if a host receives a prefix over DHCPv6 PD, then a
router connected to the host has to create a routing entry that forwards
the prefix to link local address of the host (as found in the DHCPv6 requests).

How is the delegating router supposed to know this? If we have special
treatment for hosts, then another option would be to logically assign the
addresses to the ethernet interface, perform DAD and have other nodes
perform ND.

But I have no idea how that should be signalled. Manual configuration
on the delegating router? 

Consistency with CPE behavior suggests that hosts should never assign
addresses to the (upstream) link and therefor not perform DAD on those
addresses.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 3 Nov 2015 23:30:38 +0000

Hi - let's lay this out fully so we can clearly understand the DAD implications.

Let's say a node 'N' has a WAN interface (the one that connects to the provider
network), a loopback interface, and a LAN interface (the one that connects to
tethered hosts/networks). 'N' sends a DHCPv6 PD Solicit over the WAN interface
and receives a prefix delegation 'P'. 'N' can now assign prefix 'P' to either the
loopback interface or the LAN interface, but MUST NOT assign 'P' to the WAN
interface. Now let's look at three cases:

1) 'N' assigns 'P' to the LAN interface and configures an address 'A' from 'P' that
   it also assigns to the LAN interface. 'N' MUST do DAD on the LAN interface for
   address 'A', but does not do DAD on the WAN interface because 'P' is not
   assigned to that interface.

2) 'N' assigns 'A' and 'P' to the loopback interface. 'N' does not do DAD
    on either the LAN or the WAN interface.

3) 'N' assigns 'P' to the loopback interface and assigns 'A' to the WAN interface.
    Again, 'N' does not do DAD on the WAN interface because (again) 'P' is not
    assigned to that interface.

Now, stepping back, outside observers (e.g., neighbors on the WAN link)
are completely oblivious to the way 'N' provisions 'P' and 'A' internally. All an
outside observer can tell is that 'N' emanates packets with source address
'A', and that 'P' is not on link. Therefore, there is no DAD required on the
WAN interface.

Thanks - Fred

> Sent: Tuesday, November 03, 2015 2:37 PM
> Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
> 
> Hi Brian,
> 
> > >>>>> I'm not opposed to adding a line to the table, though I don't think it provides much value - if we put our mind to it, I'm sure
> we
> > >> could
> > >>>> because if you use DHCPv6 PD you can't assign address space to an unlimited number of endpoints - you are limited to
> however
> > >> many
> > >>>> /64s you have available.
> > >>>>>
> > >>>>> If you use IA_NA or SLAAC, any network with a /64 subnet has, at least in theory, an "unlimited" number of addresses to
> assign
> > to

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 6 Nov 2015 02:21:50 +0000

Hi Lorenzo,

> On Tue, Nov 3, 2015 at 11:55 AM, Alexandre Petrescu <[email-masked]> wrote:

In order to address these points, and to get out of the way of the work
you are doing, I wrote up a draft that discusses the DAD implications of mutli
addressing. Please have a look and send  comments.

Thanks - Fred

---
A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Delegating a Prefix to a Host for Multi-addressing Purposes
        Author          : Fred L. Templin
	Filename        : draft-templin-v6ops-pdhost-00.txt
	Pages           : 6
	Date            : 2015-11-05

Abstract:
   IPv6 prefixes are typically delegated to requesting routers which
   then use them to number their downstream-attached links and networks.
   The requesting router then acts as a router between the downstream-
   attached hosts and the upstream provider network.  The router could
   also act as a host under the weak end system model, and otherwise
   behaves as a standard router.  This document considers the case when
   the "requesting router" is actually a host, and receives a prefix
   that it can use for multi-addressing purposes.  The host does not
   connect any downstream-attached networks, and uses the prefix solely
   for its own multi-addressing purposes.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-templin-v6ops-pdhost-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Mukom Akong T." <[email-masked]>
Date: Sun, 8 Nov 2015 10:21:05 +0400

On 4 November 2015 at 03:30, Templin, Fred L <[email-masked]>
wrote:

> tethered hosts/networks).

If N is a node on a LAN, then it's 'WAN' interface is simply its Ethernet
or Wireless link and the it's 'provider' could be the subnet router. It's
'LAN' interfaces will be some virtual interfaces belonging to VMs for
example.

> 'N' sends a DHCPv6 PD Solicit over the WAN interface

This is correct, since this WAN interface would have already gotten
legitimate non-link-local addresses by other means. The host would then be
requesting a PD only for other interfaces apart from the WAN interface.

> Now let's look at three cases:
>

Isn't DAD done on addresses rather than prefixes? DAD will be done on A
because it is a full address (128 bits) that will be binded to the LAN
interface.

The language of 'assigning' a prefix to an interface is a bit confusing.
The current mechanisms for doing this today (creating a ND PIO for prefix P
or having P as some DHCPv6 scope) should not trigger DAD.

>     on either the LAN or the WAN interface.

Correct, DAD is triggered per address per interface of N. Only one address
is being given to an interface (the loopback) and DAD will be done for
that. Again the use of 'assign' as applied to a prefix here is confusing .
One doesn't 'assign' a prefix to an interface and especially not loopback
interface AFAIK. There's no reason to do DAD on LAN/WAN interfaces because
no address is being assigned to them.

>     assigned to that interface.

I don't think this  is correct. DAD will be done for the WAN interface for
address A irrespective of whether P is 'assigned' to it (just as DAD is
performed for Link Local Addresses). If my understanding of your use of
'assigning' P is correct, then it could take the form of P being sent in a
PIO of a RA with A = 1. That act has no bearing on whether DAD is performed
until a host takes P, generates an IID and tries to assign it to an
interface.

> are completely oblivious to the way 'N' provisions 'P' and 'A' internally.

Correct.

> All an

If N is a host on a LAN (which requests a PD for VMS), then its WAN
interface is actually a LAN interface. Assuming it already provisioned an
address for that WAN interface, it doesn't need to provision A from the
delegated prefix. However I don't see any reason why it cannot provision an
address A from a sub-prefix (P') where P' is a sub prefix of P (e.g. it
gets a /60 P via PD, provisions a /64 P' and assigns address A out of P').
DAD must be done for that address A.

> > Subject: Re: [v6ops] DAD again [was:
> draft-ietf-v6ops-host-addr-availability discussion]
> >
> > Hi Brian,
> >
> assign addresses
> > > >>>>> On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L <
> [email-masked]<mailto:[email-masked]>> wrote:
> in Table 1,
> IA_NA/IA_TA
> gets a /64 prefix entirely for its own use, it still needs to do DAD
> > > with
> “A”, then it needs
> on interface “B”.
> endpoints", why does
> assigning addresses to devices that connect to it. Therefore, it says
> > > "no"
> unlimited number of endpoints - you are limited to
> > however
> > > >> many
> > > >>>> /64s you have available.
> > > >>>>>
> least in theory, an "unlimited" number of addresses to
> > assign
> > > to

-- 

Mukom Akong T.

LinkedIn:Mukom <https://www.linkedin.com/in/mukom>  |  twitter:
@perfexcellent

------------------------------------------------------------------------------------------------------------------------------------------
“When you work, you are the FLUTE through whose lungs the whispering of the
hours turns to MUSIC" - Kahlil Gibran
-------------------------------------------------------------------------------------------------------------------------------------------

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 9 Nov 2015 19:59:30 +0000

Hello Mukom,

See below for my responses.

Fred

From: Mukom Akong T. [mailto:[email-masked]]
Sent: Saturday, November 07, 2015 10:21 PM
To: Templin, Fred L
Cc: Brian E Carpenter; Lorenzo Colitti; [email-masked]
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

On 4 November 2015 at 03:30, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi - let's lay this out fully so we can clearly understand the DAD implications.

If N is a node on a LAN, then it's 'WAN' interface is simply its Ethernet or Wireless link and the it's 'provider' could be the subnet router. It's 'LAN' interfaces will be some virtual interfaces belonging to VMs for example.

FLT >>> Let's use as example an enterprise mobile device such as a tablet. The
FLT>>> tablet has a WiFi interface, and let's say it has some virtual interfaces
FLT>>> belonging to VMs using the example you provided. In that case, what
FLT>>> I am calling "WAN" is actually the "WiFI" interface, and what I am
FLT>>> calling "LAN" is the internal virtual interfaces, yes.

This is correct, since this WAN interface would have already gotten legitimate non-link-local addresses by other means.

FLT>>> Not necessarily; the WAN interface could be on a link that provides
FLT>>> link-local-only addressing, for example.

The host would then be requesting a PD only for other interfaces apart from the WAN interface.

FLT>>> Correct.

Isn't DAD done on addresses rather than prefixes? DAD will be done on A because it is a full address (128 bits) that will be binded to the LAN interface.

FLT>>> Yes, DAD is done when an address 'A' is assigned to an interface over which
FLT>>> DAD is required - for every such address 'A'.

The language of 'assigning' a prefix to an interface is a bit confusing. The current mechanisms for doing this today (creating a ND PIO for prefix P or having P as some DHCPv6 scope) should not trigger DAD.

FLT>>> Assigning a prefix to an interface does not invoke DAD; only assigning
FLT>>> addresses to an interface over which DAD is required invokes DAD.

Correct, DAD is triggered per address per interface of N. Only one address is being given to an interface (the loopback) and DAD will be done for that.

FLT>>> No, loopback is an example of an interface where DAD is not required.

Again the use of 'assign' as applied to a prefix here is confusing . One doesn't 'assign' a prefix to an interface and especially not loopback interface AFAIK.

FLT>>> The correct language per RFC4861 is to "[add the prefix] to the Prefix List" of the
FLT>>> interface to which the prefix is being applied. So, yes, my terminology was loose
FLT>>> but "add the prefix to the Prefix List" is what I intended.

There's no reason to do DAD on LAN/WAN interfaces because no address is being assigned to them.

FLT>>> Right.

I don't think this  is correct. DAD will be done for the WAN interface for address A irrespective of whether P is 'assigned' to it (just as DAD is performed for Link Local Addresses).

FLT>>> RFC4862 says:
FLT>>>    -  An interface whose DupAddrDetectTransmits variable is set to zero
FLT>>>       does not perform Duplicate Address Detection.
FLT>>> This shows that the node has latitude in when it can deem DAD as unnecessary
FLT>>> for a given interface. In this case, the address A is not matched by a prefix in the
FLT>>> Prefix List for the WAN interface and it is known that the prefix will never
FLT>>> never be added to the Prefix List for the WAN interface by node N nor any
FLT>>> node on the WAN link.

If my understanding of your use of 'assigning' P is correct, then it could take the form of P being sent in a PIO of a RA with A = 1. That act has no bearing on whether DAD is performed until a host takes P, generates an IID and tries to assign it to an interface.

FLT>>> The P that I am talking about is one which has been delegated to node N
FLT>>> for that node's exclusive use, and MUST NOT be considered on-link on
FLT>>> the WAN interface. Details of the delegation (whether it be DHCPv6 PD,
FLT>>> manual configuration, or something else) are irrelevant.

Correct.

All an

If N is a host on a LAN (which requests a PD for VMS), then its WAN interface is actually a LAN interface. Assuming it already provisioned an address for that WAN interface, it doesn't need to provision A from the delegated prefix. However I don't see any reason why it cannot provision an address A from a sub-prefix (P') where P' is a sub prefix of P (e.g. it gets a /60 P via PD, provisions a /64 P' and assigns address A out of P').

FLT>>> Yes, there is ambiguity in the terms "WAN" and "LAN". What is intended in
FLT>>> this discussion however is that "WAN" means the upstream interface attached
FLT>>> to the provider network and "LAN" means the downstream-attached virtual or
FLT>>> physical interfaces of node N.

FLT>>> No; not at all. A is derived from a prefix P hat is delegated for N's exclusive
FLT>>> use and is guaranteed to not be on-link on the WAN interface. DAD is
FLT>>> therefore not required on the WAN interface

Thanks - Fred
[email-masked]<mailto:[email-masked]>

> From: v6ops [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Templin, Fred L
> Cc: [email-masked]<mailto:[email-masked]>
> > From: Brian E Carpenter [mailto:[email-masked]<mailto:[email-masked]>]
> > Cc: [email-masked]<mailto:[email-masked]>
> > >> From: Brian E Carpenter [mailto:[email-masked]<mailto:[email-masked]>]
> > >> Cc: [email-masked]<mailto:[email-masked]>
> > >>>> From: Brian E Carpenter [mailto:[email-masked]<mailto:[email-masked]>]
> > >>>> Cc: [email-masked]<mailto:[email-masked]>
> > >>>>> Bumping up one level - is it clear to everyone that it is OK to assign addresses
> [email-masked]<mailto:[email-masked]>
>
> >    Brian
> >
> > >
> > > Thanks - Fred
> > > [email-masked]<mailto:[email-masked]>
> > >
> > >>> [email-masked]<mailto:[email-masked]>
> > >>>
> > >>>>     Brian
> > >>>>
> > >>>>>
> > >>>>> Thanks - Fred
> > >>>>>
> > >>>>> From: v6ops [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Templin, Fred L
> > >>>>> Cc: [email-masked]<mailto:[email-masked]>
> > >>>>> From: Lorenzo Colitti [mailto:[email-masked]<mailto:[email-masked]>]
> > >>>>> Cc: Fred Baker (fred); [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> > >>>>> On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> > >>>>> What I mean is "Requires DAD on the interface over which the prefix was received",
> > >>>>> but that was too long to fit in the table. Let's call the interface "A". If the node gets
> > >>>>> SLAAC addresses or DHCP IA_NA/IA_TA addresses over interface "A", then it needs
> > >>>>> to do DAD on interface "A" for each such address. If the node gets a DHCPv6 PD
> > >>>>> over interface "A", however, it does not need to do DAD over interface "A" at all.
> > >>>>>
> > >>>>> If the node assigns the delegated prefix to interface "B", then you are right that
> > >>>>> that DAD will be required among all tethered devices, VMs, etc. on interface "B".
> > >>>>> But, there will still be no need for DAD on interface "A". Does that clarify?
> > >>>>>
> > >>>>> I don't understand this. True that SLAAC and DHCPv6 IA_NA/IA_TA can be used
> > >>>>> to assign an unlimited number of addresses to interface "A". But, so can DHCPv6
> > >>>>> many unique IPv6 addresses as it likes to interface "A". And again, it need not
> > >>>>> do DAD for any of them.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

--

Mukom Akong T.

LinkedIn:Mukom<https://www.linkedin.com/in/mukom>  |  twitter: @perfexcellent
------------------------------------------------------------------------------------------------------------------------------------------
"When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran
-------------------------------------------------------------------------------------------------------------------------------------------

---

From: 神明達哉 <[email-masked]>
Date: Thu, 12 Nov 2015 18:36:27 -0800

At Mon, 9 Nov 2015 19:59:30 +0000,

> FLT>>> node on the WAN link.

I think I understand what you are trying to say, and I tend to agree
that it would be quite unlikely that someone else than node 'N' is
using address 'A' in the WAN link in practice in this scenario.
However, I think it's dangerous to just jump to the conclusion that
DAD is not necessary in this case in some kind of standard document.
In my understanding, DAD is designed to cover "quite unlikely
scenarios" including cases with some broken implementations/operation.
In this particular scenario, I would say that the original intent of
DAD covers an "unlikely" case where the remote (or some other,
depending the type of link) node of the WAN link is broken or some
invalid operation and is actually using address "A".

I would not necessarily be opposed to the idea of allowing this
particular use case to set DupAddrDetectTransmits to 0, but I don't
think we can casually say so in
draft-ietf-v6ops-host-addr-availability.  IMO, that would require a
separate standard track document that updates RFC4862 with providing
sufficient rationale of why this can be considered an exception (and
why it's that important).

--
JINMEI, Tatuya

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Nov 2015 12:06:55 +0900

> invalid operation and is actually using address "A".

RFC 4862 is says:   Duplicate Address Detection MUST be performed on all
unicast addresses prior to assigning them to an interface.

That is true in almost all cases, including DHCPv6 PD. For example, if a
device gets a /64 via DHCPv6 PD, and shares that /64 via a wifi hotspot,
then any address that the device itself forms out of that /64 MUST perform
DAD so that other devices connected to the wifi hotspot do not use the same
address.

At most we could slightly amend this to ..."MUST be performed on all
unicast addresses prior to assigning them to an interface except a loopback
interface". Even node-internal interfaces are not necessarily safe to omit
DAD on. For example, in a mobile device the application processor and
baseband processor might both be on the same link, and because they are two
separate processors running two separate network stacks, they need to do
DAD.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 13 Nov 2015 12:31:24 +0000

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Thursday, November 12, 2015 10:07 PM
To: 神明達哉
Cc: [email-masked]
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

>At most we could slightly amend this to ..."MUST be performed on all unicast addresses prior to assigning them to an interface except a loopback interface". Even node-internal interfaces are not >necessarily safe to omit DAD on. For example, in a mobile device the application processor and baseband processor might both be on the same link, and because they are two separate processors >running two separate network stacks, they need to do DAD.

Appendix A of RFC4862 already cautions against a loopback interface looping back DAD probes.  Did you have any other reason to disable DAD for a loopback interface?  For example, on a router, a loopback interface is configured and the IPv6 address on the interface is used to source packets.  Why would one not perform DAD for the IPv6 address used by the loopback interface?

Thanks,

Hemant

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 13 Nov 2015 13:56:39 +0100

Le 13/11/2015 13:31, Hemant Singh (shemant) a écrit :
>
>
> From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo
> Colitti Sent: Thursday, November 12, 2015 10:07 PM To: 神明達哉 Cc:
> [email-masked] Subject: Re: [v6ops] DAD again [was:
>> At most we could slightly amend this to ..."MUST be performed on
>> all unicast addresses prior to assigning them to an interface
>> except a loopback interface". Even node-internal interfaces are not
>> >necessarily safe to omit DAD on. For example, in a mobile device
>> the application processor and baseband processor might both be on
>> the same link, and because they are two separate processors
>> >running two separate network stacks, they need to do DAD.
>
> Appendix A of RFC4862 already cautions against a loopback interface
> looping back DAD probes.  Did you have any other reason to disable
> DAD for a loopback interface?  For example, on a router, a loopback
> interface is configured and the IPv6 address on the interface is used
> to source packets.  Why would one not perform DAD for the IPv6
> address used by the loopback interface?

One wouldnt care about DAD on loopback interface, because it's not noise 
on a wire, and it's not time consuming.

Alex

>
> Thanks,
>
> Hemant _______________________________________________ v6ops mailing

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 13 Nov 2015 14:00:18 +0100

Le 13/11/2015 04:06, Lorenzo Colitti a écrit :
> On Fri, Nov 13, 2015 at 11:36 AM, 神明達哉 <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> scenarios" including cases with some broken
> implementations/operation. In this particular scenario, I would say
> that the original intent of DAD covers an "unlikely" case where the
> remote (or some other, depending the type of link) node of the WAN
> link is broken or some invalid operation and is actually using
> address "A".
>
>
> RFC 4862 is says:   Duplicate Address Detection MUST be performed on
> all unicast addresses prior to assigning them to an interface.
>
> That is true in almost all cases, including DHCPv6 PD. For example,
> if a device gets a /64 via DHCPv6 PD, and shares that /64 via a wifi
> hotspot, then any address that the device itself forms out of that
> /64 MUST perform DAD so that other devices connected to the wifi
> hotspot do not use the same address.

YEs, but there are additional cases of assigning an address of the 
delegated prefix.  The device is a non-tethering device, forms an 
address out of the delegated prefix, and assigns it on its egress interface.

Since the prefix is delegated to that device exclusively then the device 
is safe to assume no-one else would form an address ouf of it.  Hence no 
need of DAD.

>  unicast addresses prior to assigning them to an interface except a
> loopback interface".

That sounds reasonable for the loopback interface.

Alex

  Even node-internal interfaces are not
> necessarily safe to omit DAD on. For example, in a mobile device the
> application processor and baseband processor might both be on the
> same link, and because they are two separate processors running two
> separate network stacks, they need to do DAD.
>
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 13 Nov 2015 13:58:04 +0000

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Friday, November 13, 2015 7:57 AM
To: [email-masked]
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

>One wouldnt care about DAD on loopback interface, because it's not noise on a wire, and it's not time consuming.

So how will you deal with a duplicate IPv6 address configured on a loopback interface?  As I said in my example, a router is using the IPv6 address on a loopback interface to source packets and a duplicate is detected - the network breaks down.

Hemant

---

From: Gert Doering <[email-masked]>
Date: Fri, 13 Nov 2015 15:08:30 +0100

Hi,

On Fri, Nov 13, 2015 at 01:58:04PM +0000, Hemant Singh (shemant) wrote:
> So how will you deal with a duplicate IPv6 address configured on a 
> loopback interface?  

We don't care.  Loopbacks imply a routing table entry somewhere to make
the packets actually reach this host - and this should ensure it's reaching
only the intended host (or you have dns-root style anycasting)

> As I said in my example, a router is using the IPv6 address on a loopback interface to source packets and a duplicate is detected - the network breaks down.

The upstream router should reject packets coming from a downstream which
is not permitted to use an IPv6 address.

Otherwise, there is no way to ensure uniqueness on non-directly-connected
interfaces - think "loopback on a router on the other side of the planet".

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 13 Nov 2015 15:34:11 +0000

-----Original Message-----
From: Gert Doering [mailto:[email-masked]] 
Sent: Friday, November 13, 2015 9:09 AM
To: Hemant Singh (shemant)
Cc: Alexandre Petrescu; [email-masked]
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

>The upstream router should reject packets coming from a downstream which is not permitted to use an IPv6 address.

Based on what?  ACL or DAD detection on the upstream router? For certain routing cases, your point is reasonable.  However, two routers may have their interfaces in the same routed domain in which case the interface responds to ND address resolution messages.  Anytime an interface responds to ND address resolution messages, the interface performs DAD for its IPv6 address(es). 

RFC4862 also supports DupAddrDetectTransmits to be zero for certain links.  Why not use this variable to disable DAD for interfaces on certain links.

>Otherwise, there is no way to ensure uniqueness on non-directly-connected interfaces - think "loopback on a router on the other side of the planet".

The router on the other side of the planet has a tunnel to the upstream router and thus the two routers are in the same routed domain.  In the same routed domain, an interface on a router responds to ND NS messages for address resolution.  Thus the interface has to also perform DAD for its IPv6 address(es).

Hemant

---

From: Gert Doering <[email-masked]>
Date: Fri, 13 Nov 2015 16:43:19 +0100

Hi,

> The router on the other side of the planet has a tunnel to the upstream router and thus the two routers are in the same routed domain.  In the same routed domain, an interface on a router responds…

Well, if you take an address that belongs to a connected /64 and glue that
to your loopback interface, what you say is true - there will be ND NS
queries for that address, and you better should do DAD.

In the normal case for loopback interfaces, these intentionally are *not*
numbered out of connected networks, but coming out of separately assigned
number space (like, DHCPv6PD, or manually configured).  Why would anyone
send a ND NS for such an address in the first place?  Nobody knows that
it "could be on a link here".

And no, the router on the other side of the planet has no "tunnel" to 
your routing domain.  It's just a router having a loopack address, 
chosen to show that your concerns about loopback address DAD are a bit
unrealistic.

Gert Doering
        -- NetMaster

---

From: Owen DeLong <[email-masked]>
Date: Fri, 13 Nov 2015 09:43:03 -0800

> On Nov 13, 2015, at 05:58 , Hemant Singh (shemant) <[email-masked]> wrote:
> 
> 

How is it possible to have a duplicate address on a loopback interface?

If you assign an address to a loopback interface, the address is present on the interface. If you attempt to assign it there again, it should be a no-op.

To the best of my knowledge, it is impossible to assign the same address to the same interface twice.

The duplicate address case applies when two systems on the same link have the same address. Since there is never more than one system on a loopback link by definition, it seems to me that the scenario you propose is impossible by definition.

Owen

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 13 Nov 2015 19:36:21 +0000

-----Original Message-----
From: Owen DeLong [mailto:[email-masked]] 
Sent: Friday, November 13, 2015 12:43 PM
To: Hemant Singh (shemant)
Cc: Alexandre Petrescu; [email-masked]
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

>How is it possible to have a duplicate address on a loopback interface?

A router configures a loopback interface and provisions an IPv6 address on the interface.  The is a LAN in the router downstream port which the router destines packets to using the source as the IPv6 address on the loopback.  The LAN segment may have a duplicate unless the loopback IPv6 address is disjoint from any IPv6 prefix on the router and router LAN/WAN segment.   Another use case is already mentioned in this thread - two routers directly connected.

Hemant

---

From: Owen DeLong <[email-masked]>
Date: Fri, 13 Nov 2015 12:41:15 -0800

> On Nov 13, 2015, at 11:36 , Hemant Singh (shemant) <[email-masked]> wrote:
> 

Sure, but in such a case, DAD on the LAN interface wouldn’t detect the loopback nor would DAD on the loopback interface.

Owen

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 13 Nov 2015 22:00:08 +0000

-----Original Message-----
From: Owen DeLong [mailto:[email-masked]] 
Sent: Friday, November 13, 2015 3:41 PM
To: Hemant Singh (shemant)
Cc: Alexandre Petrescu; [email-masked]
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

>Sure, but in such a case, DAD on the LAN interface wouldn’t detect the loopback nor would DAD on the loopback interface.

If the loopback interface issues a DAD probe and if the router sends the probe out the outbound interface, another host on the LAN segment does see the DAD probe.  On detecting a duplicate, another node sends an NA to signal a Dup.  The NA does reach the router's outbound interface and then the router knows the IPv6 address provisioned on the loopback interface and thus cannot be used

An app such as tftpv6 or NTPv6 uses IPv6 global address of the loopback interface as source IPv6 address.   If a duplicate exists in the LAN segment, couldn't the tftpv6 or NTPv6 server responses head to the dup in the LAN instead of the loopback interface on the router?

If a loopback interface does not perform DAD, then use a configuration on the loopback interface to set DupAddrDetectTransmits to zero.  Why change other text in RFC4861 to special-case a loopback interface to be excluded for DAD.

Hemant

---

From: Owen DeLong <[email-masked]>
Date: Fri, 13 Nov 2015 14:49:00 -0800

> On Nov 13, 2015, at 14:00 , Hemant Singh (shemant) <[email-masked]> wrote:
> 
> 

Sure, but you’re talking about this like the interface is autonomous from the operating system in this process which is absurd.

An interface doesn’t issue a DAD probe, the operating system does. The operating system, further, sends those out on the interface where the address in question is to be configured.

I suppose if the interface is a member of a bridge group (e.g. lo0 and eth0 are both members of br125 and the address in question is being configured on br125), then you would see the DAD request sent to both eth0 and lo0 as they are part of a common link (from the OS perspective, it is sent to br0 which in turn invokes the bridging driver which would deliver the packets in question to lo0 and eth0 as a result of the bridge group definition).

Short of that, however, the behavior you describe doesn’t match my understanding of the reality in any modern operating system with which I am familiar.

In most circumstances, it’s far from desirable to have addresses from the same subnet on different links separated by a router. (lo0 is separated from eth0 by the host in question which is acting as a router if it accepts packets on eth0 for destination address(es) configured on lo0 whether you want to admit this to yourself or not). In fact, most properly designed routers will flag such configurations as an error and refuse to install them.

> An app such as tftpv6 or NTPv6 uses IPv6 global address of the loopback interface as source IPv6 address.   If a duplicate exists in the LAN segment, couldn't the tftpv6 or NTPv6 server responses h…

You’re talking about a strange corner case with a misconfigured router. Not sure why we should waste time engineering for such brokenness in the first place.

> If a loopback interface does not perform DAD, then use a configuration on the loopback interface to set DupAddrDetectTransmits to zero.  Why change other text in RFC4861 to special-case a loopback…

I would argue that DAD on a lo interface is an absurd concept. By definition the addresses on a lo interface should not be outside of the exclusive control of the host in question and it should know all addresses in use on the lo interface.

The lo interface should not be sharing addresses with other interfaces unless they are members of a common bridge interface in which case the address would not apply to lo but would, instead, apply to the bridge group.

DAD is required on a bridge group interface.

There is no need for DAD on a loopback interface in any sane configuration.

Owen

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 13 Nov 2015 23:06:22 +0000

-----Original Message-----
From: Owen DeLong [mailto:[email-masked]] 
Sent: Friday, November 13, 2015 5:49 PM
To: Hemant Singh (shemant)
Cc: Alexandre Petrescu; [email-masked]
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

>I would argue that DAD on a lo interface is an absurd concept. By definition the addresses on a lo interface should not be outside of the exclusive control of the host in question and it should know all >addresses in use on the lo interface.

Where does the buck stop? If the lo interface does not perform DAD, the interface should not join the all-nodes and its solicited-node multicast address?   The lo interface should not support ND address resolution either.  The interfaces ends up not supporting any ND nor any DAD.

If the lo interface does not perform DAD, as I said before, set the DupAddrDetectTransmits variable for the interface to be zero. 

Hemant

---

From: Owen DeLong <[email-masked]>
Date: Fri, 13 Nov 2015 15:15:48 -0800

> On Nov 13, 2015, at 15:06 , Hemant Singh (shemant) <[email-masked]> wrote:
> 
> 
> 

Let me try and be more clear since you seem determined to follow reductio ad absurdum.

A LO interface may, but does not need to perform DAD as far as I am concerned. Sure, if it’s convenient for the coders, the performance impact is negligible and it keeps code paths consistent reducing the potential for bugs.

However, there’s no benefit. An LO address can’t have any address on it not assigned under the exclusive control of the host on which the LO interface is being managed, by definition, so it’s impossible for there to be a duplicate.

However, that does not mean that those addresses don’t need to work with ND correctly as it may well be that application A binds to one address on LO and communicates with an entirely different address also on LO to carry out transactions with application B. As a result, A will need to be able to discover the link layer address for B, effectively.

Arguably, ND isn’t necessary since the LO binding should take care of this, but most operating systems don’t bother to special case this as the effort offers little reward and substantial complexity.

> If the lo interface does not perform DAD, as I said before, set the DupAddrDetectTransmits variable for the interface to be zero. 

I have no problem with that. Just saying that there’s no need for LO to perform DAD in any sane configuration. Probably no reason for LO not to default to DupAddrDetectTransmits=0 as well.

Owen

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 13 Nov 2015 23:44:35 +0000

-----Original Message-----
From: Owen DeLong [mailto:[email-masked]] 
Sent: Friday, November 13, 2015 6:16 PM
To: Hemant Singh (shemant)
Cc: Alexandre Petrescu; [email-masked]
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

>A LO interface may, but does not need to perform DAD as far as I am concerned. Sure, if it’s convenient for the coders, the performance impact is negligible and it keeps code paths consistent reducing >the potential for bugs.

Please reply to my comment where I said if the lo does not perform DAD, then the lo does not have to join the all-nodes and the solicited-node multicast addresses.   One has to look at the comprehensive picture.   A NA signaling a DAD dup is destined to the all-nodes multicast destination - but the lo interface has disabled DAD.   So why join the all-nodes address or the solicited-node multicast address?  If the interface is also not initiating nor replying to any address resolution, there is not ND operation required on this lo interface.

>However, that does not mean that those addresses don’t need to work with ND correctly as it may well be that application A binds to one address on LO and communicates with an entirely different >address also on LO to carry out transactions with application B. As a result, A will need to be able to discover the link layer address for B, effectively.

No.  The lo interface forwards a packet to the outbound interface which performs any ND address resolution. 

>Arguably, ND isn’t necessary since the LO binding should take care of this, but most operating systems don’t bother to special case this as the effort offers little reward and substantial complexity.

Please note IPv6 ND and DAD are interface-scoped.   An OS has to confirm to interface-specific IPv6 DAD and ND properties. 

Hemant

---

From: Owen DeLong <[email-masked]>
Date: Fri, 13 Nov 2015 16:06:13 -0800

> On Nov 13, 2015, at 15:44 , Hemant Singh (shemant) <[email-masked]> wrote:
> 
> 
> 

Depending on the implementation, it may be needed for neighbor discovery/reachability, though admittedly this is unlikely.

Solicited Node and all-nodes are used for several things besides just DAD.

I don’t see the relationship that you are seeing or at least I don’t see it as being the only relationship in question.

> No.  The lo interface forwards a packet to the outbound interface which performs any ND address resolution. 

Not in any implementation I am aware of. Why would you expect such a thing?

Why would the LO address be on the same subnet as any “outbound” interface?

Your argument here appears nonsensical to me.

> Please note IPv6 ND and DAD are interface-scoped.   An OS has to confirm to interface-specific IPv6 DAD and ND properties. 

Yes… hence my confusion about your statements and questions above.

Even though they are interface-scoped, every interface on the system may use the same code paths for ND and DAD, in which case the LO interface may (unnecessarily) implement ND and/or DAD for convenience.

Owen

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 14 Nov 2015 00:36:03 +0000

-----Original Message-----
From: Owen DeLong [mailto:[email-masked]] 
Sent: Friday, November 13, 2015 7:06 PM
To: Hemant Singh (shemant)
Cc: Alexandre Petrescu; [email-masked]
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

> Solicited Node and all-nodes are used for several things besides just DAD.

I already said the lo interface does not perform DAD nor any ND operations.   If the lo interface does not perform DAD nor any ND address resolution, nor issue any redirects, why is the interface performing NUD?  Please discuss such issues in the 6man mailer. 

>Not in any implementation I am aware of. Why would you expect such a thing?

This is my last email on the subject.   Any further discussion should be moved to the 6man WG in the IETF, not v6ops, since protocol changes to RFC4862 are being discussed - I agree with Jinmei's reply to this thread.   For example, the router is provisioned for the tftpv6 client app to use the lo interface for source IPv6 address.  The outbound interface is eth0.   When the tftpv6 client sends a req packet out eth0, if the destination of the packet is an incomplete nor non-existent entry in the neighbor cache, the outbound interface issues a ND address resolution.  I cleared the neighbor cache on my router and then issued a ping to a northbound node and used the source of the ping as the lo interface. 

routeri#sh ipv6 int br lo0
Loopback0              [up/up]
    FE80::C614:3CFF:FE17:1C00
    2004::1
routeri#clear ipv6 neigh                                  
routeri#
router#ping 2001:db8:3800:800:250:56FF:FEB2:F11D source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:db8:3800:800:250:56FF:FEB2:F11D, timeout is 2 seconds:
Packet sent with a source address of 2004::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
router#

Hemant

---

From: Gert Doering <[email-masked]>
Date: Sat, 14 Nov 2015 19:12:40 +0100

Hi,

> Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

This, actually, is a totally meaningless example.

I can send packets round the world with any source address I choose, and
it has no significance for on-link NS or DAD with the *on-link* address
of intermediate network segments.

If you look more closely at your box, you'll see that it will not use the
2004::1 source address for ND on the next-hop lan interface.

Gert Doering
        -- NetMaster

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 14 Nov 2015 18:48:06 +0000

-----Original Message-----
From: Gert Doering [mailto:[email-masked]] 
Sent: Saturday, November 14, 2015 1:13 PM
To: Hemant Singh (shemant)
Cc: Owen DeLong; [email-masked]
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

>This, actually, is a totally meaningless example.

Not it's not since Owen ask that the lo interface is not in the same subnet at the outbound interface, so how is data forwarding working with ND if an address resolution is needed?  I proved data forwarding works.  I sure could have added to the example a log of the ND address resolution but any ND log is very copious due to NUD and thus I skipped the ND log. 

>I can send packets round the world with any source address I choose, and it has no significance for on-link NS or DAD with the *on-link* address of intermediate network segments.

>2004::1 source address for ND on the next-hop lan interface.

Correct.   This is what my point to Owen was.   The lo interface IPv6 address can be used to source packets out the router, and if the outbound interface has an incomplete or nonexistent entry in the neighbor cache, the outbound interfaces issues a ND address resolution and if the address resolution is completed, the packet is forwarded out.   I did issue "clear ipv6 neigh" on my router to clear the neighbor cache to force a ND address resolution.  The ND address resolution NS can use the link-local address or the global address of the outbound interface for sourcing the NS.

Hemant

---

From: Gert Doering <[email-masked]>
Date: Sat, 14 Nov 2015 19:50:52 +0100

Hi,

On Sat, Nov 14, 2015 at 06:48:06PM +0000, Hemant Singh (shemant) wrote:
> Correct.   This is what my point to Owen was.   The lo interface IPv6 
> address can be used to source packets out the router, 

Right...

> and if the outbound interface has an incomplete or nonexistent entry 
> in the neighbor cache, the outbound interfaces issues a ND address 
> resolution and if the address resolution is completed, the packet is 
> forwarded out.   

Also right.

But: the outbound interface will NOT use the lo0 source address for the ND
activity.  It will use the *interface* IP for ND, and the link-local one
for that.

There is no difference for the router between "send out a packet with a 
lo0 source to lan" and "send out a packet sourced by someone else to lan",
as far as ND activity on the LAN activity is concerned.

Surely you're not asking for a router to do DAD for every single IPv6
address that could be coming *through* that router?

> I did issue "clear ipv6 neigh" on my router to clear the neighbor cache to force a ND address resolution.  The ND address resolution NS can use the link-local address or the global address of the outbound interface for sourcing the NS.

"the global address of the outbound interface" is NOT the lo0 source address.

Gert Doering
        -- NetMaster

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 14 Nov 2015 19:03:00 +0000

-----Original Message-----
From: Gert Doering [mailto:[email-masked]] 
Sent: Saturday, November 14, 2015 1:51 PM
To: Hemant Singh (shemant)
Cc: Gert Doering; Owen DeLong; [email-masked]
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

>But: the outbound interface will NOT use the lo0 source address for the ND activity.  It will use the *interface* IP for ND, and the link-local one for that.

I already said that in my previous email.

>Surely you're not asking for a router to do DAD for every single IPv6 address that could be coming *through* that router?

No.    A router forwards packets and if the router egress interfaces fails L2-destination lookup, the interface issues a L2 address resolution.   Note, however, once a source IPv6 address of a lo interface is active to send data and the downstream LAN segment somehow has a dup, the dup issue cannot be fixed unless the router support ND Proxy which can respond.

>"the global address of the outbound interface" is NOT the lo0 source address.

Right - what is your point?  Please also see rfc5942 and section 6.  No source IPv6 address in a ND message can be used to make on on-link determination.

Hemant

---

From: Gert Doering <[email-masked]>
Date: Sat, 14 Nov 2015 20:27:40 +0100

Hi,

On Sat, Nov 14, 2015 at 07:14:28PM +0000, Hemant Singh (shemant) wrote:
> I will be out for next few hours.  I will reply to any mails after that.   I don't have any issue to disable DAD for  a lo interface.  Jinmei wants due diligence because rfc4862 is being changed and the 6man WG has to take a look.  The draft is not just a v6ops issue any more.   I also have another issue in that if DAD is disabled, what else makes sense to disable on the lo interface so that the interface has even more reduced processing to deal with. 

You do not need to disable DAD on lo.  Do it all you want.

But don't do DAD for interface A address on interface B.  This is the point
everybody has been making.

So, if you have an address on lo, there is no reason to do DAD for that
on eth0, eth1, pos3/4, or anything else in your box - as you wouldn't
do DAD for the eth0 address on eth1.

Unrelated interfaces.

And on lo0, there is no other party to conflict with, so do DAD if you 
want, or do not do DAD.  Nobody cares.

Gert Doering
        -- NetMaster

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 15 Nov 2015 00:28:18 +0000

Agreed.

Hemant

-----Original Message-----
From: Gert Doering [mailto:[email-masked]] 
Sent: Saturday, November 14, 2015 2:28 PM
To: Hemant Singh (shemant)
Cc: Gert Doering; [email-masked]
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

Hi,

But don't do DAD for interface A address on interface B.  This is the point everybody has been making.

So, if you have an address on lo, there is no reason to do DAD for that on eth0, eth1, pos3/4, or anything else in your box - as you wouldn't do DAD for the eth0 address on eth1.

Unrelated interfaces.

And on lo0, there is no other party to conflict with, so do DAD if you want, or do not do DAD.  Nobody cares.

Gert Doering
        -- NetMaster

---

From: Owen DeLong <[email-masked]>
Date: Sat, 14 Nov 2015 16:57:34 -0800

> On Nov 14, 2015, at 10:48 , Hemant Singh (shemant) <[email-masked]> wrote:
> 
> 
> 

I didn’t say you couldn’t bridge the LO and External interfaces… I said that short of doing that, having the same subnet on both interfaces is a misconfiguration.

You haven’t proven that the interfaces aren’t bridged (or effectively so), nor have you proven that they are actually on the same subnet. Ergo, it is, actually, still a meaningless example.

> Correct.   This is what my point to Owen was.   The lo interface IPv6 address can be used to source packets out the router, and if the outbound interface has an incomplete or nonexistent entry in t…

Sure, but the reply packet either has to get routed on the return (router has to somehow be a next hop for the LO prefix) or the router has to be incorrectly answering ND packets for the LO interface received on a different interface.

Owen

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 15 Nov 2015 01:21:20 +0000

-----Original Message-----
From: Owen DeLong [mailto:[email-masked]] 
Sent: Saturday, November 14, 2015 7:58 PM
To: Hemant Singh (shemant)
Cc: Gert Doering; [email-masked]
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

>You haven’t proven that the interfaces aren’t bridged (or effectively so), nor have you proven that they are actually on the same subnet. Ergo, it is, actually, still a meaningless example.

An app has decides to use the IPv6 address of the lo interface to source the app's packets.   This is what the ping command in my example decides since the command is asked to use the source of the ICMPv6 packets as the lo interface's address.  Then usual data forwarding on the router takes over.  Routing decides from the packet destination, the packet has to egress out an outbound interface, say, eth0.   However, when the packet is to be egressed out eth0, the L2 destination lookup fails.  Eth0 issues a ND address resolution to resolve the destination uses its own source interface IPv6 address.  I forced the ND address resolution by clearing the IPv6 neighbor cache on the router.   Then I proved the packet is forwarded.   There is no bridging involved and packets are sourced fine using the lo interface.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 15 Nov 2015 12:25:35 +0000

Fred,

Sorry for the delay.  I am catching up with the original thread.   Please see below.

>Sent: Monday, November 09, 2015 3:00 PM
>To: Mukom Akong T.
>Cc: [email-masked]

>This is correct, since this WAN interface would have already gotten legitimate non-link-local addresses by other means.

There is another reason.  The prefix delegation (PD) RFC in RFC3633 says

[the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating router.]

The reason RFC3633 has such a restriction is because if it were possible, then the WAN IPv6 global address is on-link to the northbound SP router.   The delegated prefix in P is supposed to be not on-link on the WAN.   Thus if a loopback (lo) interface is configured with an IPv6 address from prefix P, the  IPv6 address is not on-link and thus the lo interface does not initiate DAD for the address.

However, if an address is configured on the lo interface manually and the address is not using an address from a DHCPv6 PD, what transpires?   The intent of the admin is to configure an address which is not on-link to the directly connected network.   The only other case is if the directly connected network includes a node who manually assigned its IPv6 address (or is broken) and the address happens to match the address on the lo interface - now DAD is needed.   

Hemant

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 16 Nov 2015 16:41:30 +0000

Hi Hemant,

> From: Hemant Singh (shemant) [mailto:[email-masked]]
> Sent: Sunday, November 15, 2015 4:26 AM
> To: Templin, Fred L; Mukom Akong T.
> Cc: [email-masked]
> Subject: RE: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
> 
> Fred,
> 

OK.

> [the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it
> received the DHCP message from the delegating router.]

Correct; that is exactly why I said "MUST NOT".

> The reason RFC3633 has such a restriction is because if it were possible, then the WAN IPv6 global address is on-link to the northbound
> SP router.   The delegated prefix in P is supposed to be not on-link on the WAN.   Thus if a loopback (lo) interface is configured with an
> IPv6 address from prefix P, the  IPv6 address is not on-link and thus the lo interface does not initiate DAD for the address.
> 
> However, if an address is configured on the lo interface manually and the address is not using an address from a DHCPv6 PD, what
> transpires?   The intent of the admin is to configure an address which is not on-link to the directly connected network.   The only other
> case is if the directly connected network includes a node who manually assigned its IPv6 address (or is broken) and the address
> happens to match the address on the lo interface - now DAD is needed.

This is starting to diverge from the case I originally intended this discussion to
examine. The case I am interested in is as follows:

- Node N receives a /64 prefix delegation for prefix P over interface eth0.
- N assigns P to the lo interface as a /64 route. This is done to black-hole
   unused portions of P.
- N configures address A from prefix P, and assigns it to eth0.
- N need not perform DAD for A over eth0, because the delegating router
   has made sure that the routing system will route all packets with a
   destination address from P to node N, and not to any other node.

In this way, N can function as an ordinary host according to the strong end
system model even though it acted as a "requesting router" in procuring a
prefix from the delegating router. No other node X on the same link as
N can therefore configure an address from P and have the routing system
return packets to X. In fact, any node X that configures an address from P
can be considered an "attacker", and the use or non-use of DAD has no
way of preventing that. In fact, the use of DAD could give X a clue as to
which addresses from P are ripe for attacking. So, it is in fact better to
NOT do DAD.

Thanks - Fred

---

From: Owen DeLong <[email-masked]>
Date: Mon, 16 Nov 2015 11:47:42 -0800

> On Nov 14, 2015, at 17:21 , Hemant Singh (shemant) <[email-masked]> wrote:
> 
> 
> 

Which has exactly nothing to do with the idea of having ETH0 do DAD on an address on LO.

All I have been saying is that having an LO address on the same subnet as ETH0 without bridging is a misconfiguration.

I never said it couldn’t work. I never said it didn’t work.

Certainly at a minimum it is a recipe for a potential undetected duplicate address as the router SHOULD NOT respond to
an ND packet for it’s LO interface on ETH0 or any other non-LO interface.

Owen

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 16 Nov 2015 19:51:32 +0000

Fred,

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Monday, November 16, 2015 11:42 AM
To: Hemant Singh (shemant); Mukom Akong T.
Cc: [email-masked]
Subject: RE: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

>- N configures address A from prefix P, and assigns it to eth0.

If A from prefix P is assigned to eth0, we have violated rfc3633 which says to not assign any IPv6 address on the port on which the node received the PD from.  Did I miss anything?

Hemant

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 16 Nov 2015 20:04:44 +0000

Hi Hemant,

> Sent: Monday, November 16, 2015 11:52 AM
> If A from prefix P is assigned to eth0, we have violated rfc3633 which says to not assign any IPv6 address on the port on which the
> node received the PD from.  Did I miss anything?

Section 12.1 of RFC3633 says:

   "the requesting router MUST
   NOT assign any delegated prefixes or subnets from the delegated
   prefix(es) to the link through which it received the DHCP message
   from the delegating router."

and what I am suggesting agrees with this requirement. I am talking
about assigning *addresses* (not prefixes or subnets), and the
document does not say that an address cannot be assigned to the
link through which the DHCP message was received.

Thanks - Fred

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 16 Nov 2015 20:14:52 +0000

Fred,

Ah, even I was thinking, maybe is addresses are allowed and bingo, you caught it - thanks for the clarifications.   Your use case looks good.

Hemant

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Monday, November 16, 2015 3:05 PM
To: Hemant Singh (shemant); Mukom Akong T.
Cc: [email-masked]
Subject: RE: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

and what I am suggesting agrees with this requirement. I am talking about assigning *addresses* (not prefixes or subnets), and the document does not say that an address cannot be assigned to the link through which the DHCP message was received.

Thanks - Fred

---

From: Owen DeLong <[email-masked]>
Date: Mon, 16 Nov 2015 12:45:13 -0800

> - N configures address A from prefix P, and assigns it to eth0.

N inherently cannot do this because ETH0 is the interface on which it received the DHCPv6 PD
delegation of the /64 in question.

>   destination address from P to node N, and not to any other node.

In any case, N should not perform DAD for A over eth0 because A is not assigned to eth0.

However, I’m not sure how one can claim that a delegating router can ensure anything
about the behavior of other routers in the routing system.

It’s unclear to me why A would assign P to eth0 anyway. Why not just have the delegating
router assign addresses to other hosts on eth0? Why would A act as a gateway leading to
the delegating router on the same subnet?

I am finding your example more confusing that perhaps is intended.

Owen

> [email-masked] <mailto:[email-masked]>
> 
>> Hemant
>> 
>> 
>> 
> 
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>

---

From: Owen DeLong <[email-masked]>
Date: Mon, 16 Nov 2015 12:51:56 -0800

> On Nov 16, 2015, at 12:04 , Templin, Fred L <[email-masked]> wrote:
> 
> Hi Hemant,
> 
>   from the delegating router.”

I would argue that an address from within the prefix constitutes the same thing as a prefix in this context.

Even if it is a /128 prefix.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Nov 2015 14:45:55 +1300

I guess I've been puzzling over this for ten days, but the PD
discussion made me think about it again. Read to the end to
reload the context and seem my comment:

> source addresses of packets that pass through them.

All routers are also IPv6 nodes, and by definition have an active
IPv6 interface with an address on each of their links. All IPv6 nodes
are supposed to perform DAD on their addresses. RFC 4862 is clear that
this applies even if SLAAC is not used:

   The Duplicate
   Address Detection algorithm is performed on all addresses,
   independently of whether they are obtained via stateless
   autoconfiguration or DHCPv6.

and specifically requires routers to perform DAD:

   In addition, routers are expected to successfully pass the
   Duplicate Address Detection procedure described in this document on
   all addresses prior to assigning them to an interface.

In fact it's particularly important that routers detect any address
collision on any of their interfaces, because downstream hosts or other
routers use each address as a next hop.

I can readily believe that implementations where static addresses are
configured on a simple pt2pt link skip this, but doing so on a broadcast
or NBMA link seems wrong to me.

    Brian

     Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 17 Nov 2015 17:52:40 +0000

Hi Brian,

> Sent: Monday, November 16, 2015 5:46 PM
> Subject: Re: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
> 

RFC4862 says:

   -  An interface whose DupAddrDetectTransmits variable is set to zero
      does not perform Duplicate Address Detection.

What that means is that the node does not have to do DAD if it has some
good reason for setting DupAddrDetectTransmits to 0. Such as if the
addresses it assigns to the interface are from a prefix delegation it
has received from a delegating router.

> or NBMA link seems wrong to me.

Using AERO as an example of an NBMA link, AERO Clients autoconfigure
AERO addresses based on the prefix delegations they receive from AERO
Servers. AERO Servers MUST ensure that the prefixes they give out are
unique to the AERO Client recipient and not given out to other AERO
Clients. So, the AERO address (which is really just an IPv6 link-local
address with an IPv6 prefix embedded in the interface identifier) is
guaranteed to be unique and hence no DAD needed.

Thanks - Fred

---

From: David Schinazi <[email-masked]>
Date: Mon, 30 Nov 2015 14:52:56 -0800

David,

I believe we should not recommend limiting the number of addresses a host can use.
Networks are already free to punish misbehaving clients (by number of packets or addresses for example),
that doesn’t need to be explicitly specified in this document.

I understand your concerns about abuse, but hosts can already use this many addresses today and our document
will not impact how many addresses hosts choose to use - only how many are available to them from the network.

Thanks,
David

On November 3, 2015 at 01:16:53, David Farmer ([email-masked]) wrote:

---

From: David Farmer <[email-masked]>
Date: Mon, 30 Nov 2015 18:48:19 -0600

I don't want to specify a limit or even recommend networks set limits. 
However, no specific limit or not recommending a limit, does not mean 
its reasonable for a host to expect an unlimited number of addresses 
either.  If you can find a good way to communicate that I'll be happy.

> On November 3, 2015 at 01:16:53, David Farmer ([email-masked]
> <mailto:[email-masked]>) wrote:
>