Subject: Robert Wilton's No Objection on draft-ietf-6man-grand-06: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Thu, 01 Jul 2021 01:25:08 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-6man-grand-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-grand/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this document.  I was surprised that ND didn't already have this
behavior so its addition is clearly a good thing.

A couple of minor comments:

(1) I wasn't really familiar with the term "off-link" and I was wondering
whether it's definition should be imported here, although I note that ND does
define and use this term, so readers familiar with the ND RFC would presumably
be familiar with it.

(2) I actually found the normative text updating RFC4861 in section 6.1.1 to
not be that readable, and I had to scan it a couple of times to spot the
distinction between router and host.  Possibly laying out the text slightly
differently would make the distinction between host and router behaviour more
obvious.  E.g.,

   When a valid Neighbor Advertisement is received (either solicited or
   unsolicited), the Neighbor Cache is searched for the target's entry.
   If no entry exists:

       Hosts SHOULD silently discard the advertisement.  There is no
       need to create an entry if none exists, since the recipient has
       apparently not initiated any communication with the target.

       Routers SHOULD create a new entry for the target address with
       the link-layer address set to the Target link-layer address
       option (if supplied).  The entry's reachability state MUST be
       set to STALE.  If the received Neighbor Advertisement does not
       contain the Target link-layer address option the advertisement
       SHOULD be silently discarded.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 1 Jul 2021 22:08:36 +1000

Hi Robert,

> define and use this term, so readers familiar with the ND RFC would presumably

Yes,  the idea of off-link and on-link addresses/communication is kind
of fundamental for ND.
I'll add the following text to the Terminology section:
"On-link address: an address that is assigned to an interface on a
specified link. See Section 2.1 of [RFC4861] for detailed definition.
Off-link: the opposite of "on-link". See Section 2.1 of [RFC4861] for
detailed definition."

Would it make it better?

>        SHOULD be silently discarded.

Done, -07 will have the updated text, thanks for the suggestion!

-- 
SY, Jen Linkova aka Furry

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 1 Jul 2021 13:40:47 +0000

Hi Jen,

> -----Original Message-----
> From: Jen Linkova <[email-masked]>
> Sent: 01 July 2021 13:09
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: The IESG <[email-masked]>; Bob Hinden <[email-masked]>; draft-
> [email-masked]; 6man <[email-masked]>; 6man Chairs <6man-
> [email-masked]>
> Subject: Re: Robert Wilton's No Objection on draft-ietf-6man-grand-06: (with
> COMMENT)
> 
> Hi Robert,
> 

That would be fine with me, but I'm happy to leave it entirely to your discretion as to whether you think this is needed/useful.  As you say, probably everyone who is more familiar with ND would know this anyway ...

> Done, -07 will have the updated text, thanks for the suggestion!

Thanks,
Rob

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 1 Jul 2021 16:04:41 +0200

> Off-link: the opposite of "on-link". See Section 2.1 of [RFC4861] for

Aside from the conversation above that I agree with,  and aside of the 
fact that I agree that RFC 4861 does define the term "off-link" too by 
opposing it to a better defined "on-link" term, I must say that I never 
used or heard in practice people talking about off-link or on-link 
addresses.

If one wants to talk about off-link or on-link addresses then one talks 
about neighbors or not neighbors.

We around me usually talk casually about link-local addresses (adresses 
'lien', fr.), but we never talk about off-link or on-link addresses.

Then, there is the use of the term 'on-link' in RFC4861 which is at 
times glued to 'prefixes', even though it is formally defined to mean 
'addresses'.
For example, a full expansion of this RFC4861 text:
"These options specify the prefixes that are on-link"
would actually mean
"These options specify the prefixes that are on-link, i.e. addresses 
assigned to an interface on a specified link"
which is somehow difficult to understand.

The most confusing is probably the expansion of this text:
"L              1-bit on-link flag."
which, when expanded, it would mean
"L              1-bit on-link addresses flag"
when it is, in fact, a flag about prefixes in PIOs, and not about 
addresses.  These prefixes are often used for other operations than just 
forming addresses.  It is thus difficult to grasp.

Probably this could be solved if in the definition of 'on-link' in 
RFC4861 it said that it could also be a prefix, not just an address.

This 'on-link' and 'off-link' discussion relates a lot to the 
difficulties we have in suggesting at IETF that a new extension is 
needed to tell that a prefix advertised on a link might not be for that 
link to be used for SLAAC, but for putting in a routing table entry.  A 
little bit similar to RFC4191's RIOs.

But when told that the RIO of RFC4191 might be appropriate for the V2V 
case that I needed I always reply that what we need is an RIO that is 
always outside the link (I dont use the term 'off-link'), and always at 
least 2-hops away, never 1-hop away.  SO there I dont use either the 
on/off-link terms.

Maybe it's just me...

End of parenthesis.

Alex

---

From: Jen Linkova <[email-masked]>
Date: Fri, 2 Jul 2021 08:46:15 +1000

> used or heard in practice people talking about off-link or on-link

Well...I guess our experiences vary significantly. I hear those terms
a lot and I do use them all the time.

> about neighbors or not neighbors.

Well, strictly speaking, neighbor is a *node* attached to the same
link. Being on-link or off-link is a property (of an address, for
example).

> 'lien', fr.), but we never talk about off-link or on-link addresses.

I find the on-link/off-link terms very useful because in my work I
have to distinguish between "communication with neighbors" and
:communication with the rest of the network, via routers".
Terms like "intra-VLAN"/"inter-VLAN" are too topology-specific etc.

> forming addresses.  It is thus difficult to grasp.

I suggest you look at it from a different angle.
"on-link address" is defined as an address that is assigned to an
interface on a specified link.
There are different ways to indicate that the address is on-link and
one of them is "the address is covered by an on-link prefix, e,g, as
indicated by the on-link flag in the Prefix Information option".
L bit just indicates that addresses covered by the prefix shall be
considered on-link. That's it.

> little bit similar to RFC4191's RIOs.

OK, disclaimer: I'm writing this before my first coffee...but...L flag
has nothing to do with SLAAC, A flag is used for that.
L=1, A=0 would just mean 'addresses on that prefix are on-link but do
not use the prefix for auto-configuration'.

Smth like:

2001:db8:1::/64----node1-------node2
If node2 receives a PIO for 2001:db8:1::/64 with L=1, A=0 it would
assume that 2001:db8:1::f00, for example, is on-link and would try to
resolve its link-layer address using ND.
If node1 acts as an ND proxy, it would work.

> least 2-hops away, never 1-hop away.  SO there I dont use either the

Sorry, I've not been following that discussion. Wouldn't "L=1, A=0 +
ND proxy" do what you want?

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 5 Jul 2021 10:49:57 +0200

Le 02/07/2021 à 00:46, Jen Linkova a écrit :
[...]
> I suggest you look at it from a different angle. "on-link address" is
> defined as an address that is assigned to an interface on a specified
> link.

But, each address is on a link.

On-link means the address is on this link that we are assuming commonly.
  The term off-link means that the address is not on this link we assume
commonly, but is on-link on another link.

In the RA, where the 'on-link' prefixes are present, there is no
identifier of a link.  If there were, then we could say that that
prefix, and the SLAAC-formed addresses, were 'on-link' on the specified
link.

And, there is no address that is not on a link.  All addresses are on a
link.  Even on virtual interfaces, the 'on-link' addresses are on-link
on that virtual link.

> one of them is "the address is covered by an on-link prefix,

Conceptually, yes, but the relationship 'covered by' can not be
implemented correctly unless we specify a prefix length to input into a
matching algorithm.  It is not the plen of the prefix in the PIO, it is
a length used in a search algorithm.

Only the persons who believe that length is 64, and always 64, consider
that 'covered by' is an implementable operation.

> e,g, as indicated by the on-link flag in the Prefix Information
> option". L bit just indicates that addresses covered by the prefix
> shall be considered on-link. That's it.
> 
>> needed to tell that a prefix advertised on a link might not be for
>> that link to be used for SLAAC, but for putting in a routing table
>> entry.  A little bit similar to RFC4191's RIOs.
> 
> OK, disclaimer: I'm writing this before my first coffee...but...L
> flag has nothing to do with SLAAC, A flag is used for that. L=1, A=0
> would just mean 'addresses on that prefix are on-link but do not use
> the prefix for auto-configuration'.

'addresses on that prefix', you mean addresses whose plen is always 64, 
I think.

> 
> Smth like:
> 
> 2001:db8:1::/64----node1-------node2 If node2 receives a PIO for
> 2001:db8:1::/64 with L=1, A=0 it would assume that 2001:db8:1::f00,
> for example, is on-link and would try to resolve its link-layer
> address using ND. If node1 acts as an ND proxy, it would work.

Fair enough.  The concept of ND proxy blurs a little bit all that I have 
written above.

> 
>> But when told that the RIO of RFC4191 might be appropriate for the
>> V2V case that I needed I always reply that what we need is an RIO
>> that is always outside the link (I dont use the term 'off-link'),
>> and always at least 2-hops away, never 1-hop away.  SO there I dont
>> use either the on/off-link terms.
> 
Err, no.

What I need is a prefix in an PIO (or a RIO) of an RA that is on a link 
('on-link') situated always at least one IP hop away; it is never 
'on-link' on this link where the RA is sent. These prefixes are never 
used to form addresses elsewhere than where they are 'on-link'.

The topology is below.  Each vertical and horizontal lines are 'links'. 
  The triple dot separate links with IP routers.

R2 sends an RA towards R1 containing the P prefixes below each other 
router.  These prefixes are at least one IP hop away from R2's link on 
which it sends that RA.

        RA[P2, ...Pn] <--
     R1------------------R2---...---Rn
     |                   |P2        |Pn
     |                   |          |
   Host1               Host2      Hostn

Alex

---

From: Simon Hobson <[email-masked]>
Date: Tue, 6 Jul 2021 17:32:06 +0100

> commonly, but is on-link on another link.

Isn't it simpler than that ?
On link == hosts can directly contact other hosts in the prefix via this link
Not on link == hosts can only contact other hosts in the prefix via one or more intermediaries

Intermediary in this case is quite flexible and could include routing packets or mechanisms like proxy ND

I think any more is just making things complicated. If the link is of a type (e.g. unfiltered ethernet) where neighbours can find each other (e.g. using ND), then a prefix can be on-link. Otherwise (non-broadcast link technology, security filtering, etc), prefixes will need to be off-link.

OK, so what have I missed here ?

Simon

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 8 Jul 2021 12:19:54 +0200

> Intermediary in this case is quite flexible and could include routing packets or mechanisms like proxy ND

I think it is a good informal explanation, that fits.

However, the formal definition of 'on-link' in RFC 4861 says that 
'on-link' is an address on a specified link.  But in RAs there is no 
means to specify a link.

There are indeed prefixes that are valid on a particular link, but links 
are not identified by particular prefixes.

Further, the definition says that "a node considers an address to be 
on-link it is covered by a particular prefix".  That operation, 'being 
covered by', is not specified.

One might think of the use of a longest prefiix match algorithm.

A longest prefix match algorithm is defined in that RFC to be used to 
determine which prefix (from a set of prefixes) 'covers' an address.

On another hand, the definition of 'on-link' says it wants to identify 
whether a _particular_ prefix 'covers' an address (not to try to 
identify whether an address matches better one prefix or another).  That 
is a distinct algorithm from the longest prefix match algorithm.

To give an example: by using a longest-prefix-match algorithm in a 
normal way (identify which prefix out of a set of prefixes matches 
better one particular address) one will always 'cover' an address with 
almost any prefix.  All allocated prefixes start with this '000' triple 
bits.  So they all cover any address; but in that 'cover' operation one 
specifically adds that it covers up to 3 bits.  The 'cover' operation is 
successful, but just up to 3.

If, on the other hand, we silently assume that a longest-prefix-match 
algorithm is always used with a prefix length of precisely 64 bits, then 
indeed the longest prefix match algorithm can be used to say it 'covers' 
(or not covers) an address.

But it is no longer a longest-prefix-match but rather a mix-in of exact 
match on 64.

The problem with this assumption is that the RFC 4861 does not say this 
'64', but everyone else seems to assume it.

At that point, if this is agreed, I would like to suggest RFC4861 to 
explicitely say that all the definitions of 'on-link' and of 'cover by' 
rely on a silent yet fundamental assumptions that all IPv6 addresses 
have a boundary at 64.  And no longer be silent about it.

After that, I would like to suggest to remove that barrier.

Alex

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

---

From: Philip Homburg <[email-masked]>
Date: Thu, 08 Jul 2021 16:18:47 +0200

> Further, the definition says that "a node considers an address to
> be on-link it is covered by a particular prefix".  That operation,
> 'being covered by', is not specified.
> 
> A longest prefix match algorithm is defined in that RFC to be used
> to determine which prefix (from a set of prefixes) 'covers' an
> address.
> 
> On another hand, the definition of 'on-link' says it wants to
> identify whether a _particular_ prefix 'covers' an address (not to
> try to identify whether an address matches better one prefix or
> another).  That is a distinct algorithm from the longest prefix
> match algorithm.
> 
> To give an example: by using a longest-prefix-match algorithm in
> a normal way (identify which prefix out of a set of prefixes matches
> better one particular address) one will always 'cover' an address
> with almost any prefix.  All allocated prefixes start with this
> '000' triple bits.  So they all cover any address; but in that
> 'cover' operation one specifically adds that it covers up to 3
> bits.  The 'cover' operation is successful, but just up to 3.

I'm confused about what you are trying to say. The way I understand it is
as follows:
An RA may contain a prefix that has the onlink bit set. The interface
is implicitly defined as the interface over which the RA arrives at the
host, so there is no need to make this explicit. Information in an RA only
applies to the interface over which the RA arrives.

Then 'covered by the prefix'. Covered by the prefix 2001:db8::/80 means that
if the first 80 bits of an address are the same as the first 80 bits of the
prefix, then the address is said to be covered by the prefix. For onlink,
there is no 64-bit boundary. Any prefix length should work. The prefix
length determines how many bits are compared to decide on a match.

Then, in theory there could be overlapping prefixes, some might be onlink,
some might be not onlink. So in theory we could define a longest matching rule.
However, this leads to code complexity and there don't seem to be any
practical use cases for overlapping prefixes, so leaving this undefined
and assuming that routers do not generate RAs with overlapping prefixes
seems fine.

---

From: Simon Hobson <[email-masked]>
Date: Fri, 9 Jul 2021 16:36:16 +0100

Philip Homburg <[email-masked]> wrote:
> I'm confused about what you are trying to say.

Thanks, I was beginning to wonder if it was just me !

> The way I understand it is as follows:

That was my interpretation as well.

> length determines how many bits are compared to decide on a match.

Agreed.

> and assuming that routers do not generate RAs with overlapping prefixes

I had assumed (yes I know, that's dangerous) that overlapping prefixes would be as allowed as overlapping IPv4 subnets - as in not allowed. It would at the very least be rather poor network design since it would create completely avoidable issues like you described.

Simon

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 12 Jul 2021 13:18:08 +0000

For a more complete discussion of on/off-link, please refer to "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes", RFC 5942.
https://datatracker.ietf.org/doc/html/rfc5942

- Wes

On 7/1/21, 6:47 PM, "ipv6 on behalf of Jen Linkova" <[email-masked] on behalf of [email-masked]> wrote:

    Smth like:

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 12 Jul 2021 15:28:44 +0200

Tell me, why 64 is a default in the eyes of an impplementer when a 
length isn't specified?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 12 Jul 2021 16:04:58 +0200

I think one question might be: do we agree that each IP address is
assigned on an interface, and thus is on-link on a particular link?

For my part, I think yes, each IP address is assigned to an interface
and is on-link on a particular link.

One might also wonder: are only IPv6 addresses _not_ associated 
automatically with an IPv6 'on-link' prefixes?

For my part, I think that IPv4 addresses too are _not_ associated 
automatically with an IPv4 'on-link' prefix.

For this reason, I dont think RFC5942 is right, right from the
beginning.  Because it says:
> This document [RFC5942] spells out the most important difference:
> that an IPv6 address isn't automatically associated with an IPv6
> on-link prefix.

IPv4 addresses too can be _not_ associated with IPv4 on-link prefix.

Further, an IPv6 address not derived by SLAAC (e.g. manually assigned) 
_is_ associated with an 'on-link' prefix (the /128 covering the address 
entirely) even though it is not the prefix present in the PIO in RA 
which has this 'on-link' flag set.

Then, if I manually add this address in the Neighbour Cache of the 
router offering access, then certainly there is on-link determination 
for that address.

Alex

Le 12/07/2021 à 15:18, Wes Beebee (wbeebee) a écrit :
> For a more complete discussion of on/off-link, please refer to "IPv6 
> Subnet Model: The Relationship between Links and Subnet Prefixes", 
> RFC 5942. https://datatracker.ietf.org/doc/html/rfc5942
> 
> - Wes
> 
> On 7/1/21, 6:47 PM, "ipv6 on behalf of Jen Linkova" 
> <[email-masked] on behalf of [email-masked]> wrote:
> 
>> Aside from the conversation above that I agree with,  and aside of 
>> the fact that I agree that RFC 4861 does define the term
>> "off-link" too by opposing it to a better defined "on-link" term, I
>> must say that I never used or heard in practice people talking
>> about off-link or on-link addresses.
> 
>> If one wants to talk about off-link or on-link addresses then one 
>> talks about neighbors or not neighbors.
> 
>> We around me usually talk casually about link-local addresses 
>> (adresses 'lien', fr.), but we never talk about off-link or
>> on-link addresses.
> 
> :communication with the rest of the network, via routers". Terms
> like "intra-VLAN"/"inter-VLAN" are too topology-specific etc.
> 
>> times glued to 'prefixes', even though it is formally defined to 
>> mean 'addresses'. For example, a full expansion of this RFC4861 
>> text: "These options specify the prefixes that are on-link" would 
>> actually mean "These options specify the prefixes that are
>> on-link, i.e. addresses assigned to an interface on a specified
>> link" which is somehow difficult to understand.
>> 
>> The most confusing is probably the expansion of this text: "L 1-bit
>> on-link flag." which, when expanded, it would mean "L 1-bit on-link
>> addresses flag" when it is, in fact, a flag about prefixes in PIOs,
>> and not about addresses.  These prefixes are often used for other
>> operations than just forming addresses.  It is thus difficult to
>> grasp.
> 
> I suggest you look at it from a different angle. "on-link address"
> is defined as an address that is assigned to an interface on a
> specified link. There are different ways to indicate that the address
> is on-link and one of them is "the address is covered by an on-link 
> prefix, e,g, as indicated by the on-link flag in the Prefix 
> Information option". L bit just indicates that addresses covered by 
> the prefix shall be considered on-link. That's it.
> 
>>  needed to tell that a prefix advertised on a link might not be
>> for that link to be used for SLAAC, but for putting in a routing
>> table entry.  A little bit similar to RFC4191's RIOs.
> 
>> and always at least 2-hops away, never 1-hop away.  SO there I
>> dont use either the on/off-link terms.
> 
> -- SY, Jen Linkova aka Furry
> 
>  IETF IPv6 working group mailing list [email-masked] Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Philip Homburg <[email-masked]>
Date: Mon, 12 Jul 2021 17:19:33 +0200

> I think one question
> might be: do we agree that each IP address is assigned on an
> interface, and thus is on-link on a particular link?

This is not correct. On a NBMA link it is possible that all GUA addresses
are not on-link.

The conceptual model of on-link is that a host can use neighbor discovery
to find an onlink neighbor. If the neighbor is not on-link then traffic
has to go (at least initially) through a default router.

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 12 Jul 2021 15:34:57 +0000

NBMA or P2MP are not supported by IPv6 anyway because it is not possible to check LLA uniqueness - multicast does not work.
LLA proxy is needed on the hub site.
Ed/
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Philip Homburg
Sent: Monday, July 12, 2021 6:20 PM
To: [email-masked]
Cc: Alexandre Petrescu <[email-masked]>
Subject: Re: on-link and off-link 

> interface, and thus is on-link on a particular link?

This is not correct. On a NBMA link it is possible that all GUA addresses are not on-link.

The conceptual model of on-link is that a host can use neighbor discovery to find an onlink neighbor. If the neighbor is not on-link then traffic has to go (at least initially) through a default router.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 12 Jul 2021 16:04:00 +0000

Exactly; the model at the IP layer has to be multilink subnet.
Your link local gets you to a router but not to all in the subnet.

With IPv6 all is abstracted with multicast operations and link local addresses. 
So what IP considers a link and who belongs to a subnet (is constrained by but) does not need to match what the L2 sees, e.g., the L2 links (e.g., an ethernet wire or a radio range) and the L2 broadcast domains (e.g., a 802.1 bridged domain or a Wi-Fi ESS). 
IPv4 gave the wrong habit of thinking they have to be congruent. They don't.

Pascal

> From: ipv6 <[email-masked]> On Behalf Of Vasilenko Eduard
> Sent: lundi 12 juillet 2021 17:35
> To: Philip Homburg <[email-masked]>; [email-masked]
> Subject: RE: on-link and off-link
> 
> NBMA or P2MP are not supported by IPv6 anyway because it is not possible
> to check LLA uniqueness - multicast does not work.

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 12 Jul 2021 16:14:32 +0000

By the way,
It blocks not just native P2MP technology,
It does break any filtering, like "PVLAN" or "WiFi isolation",
Because if it is not possible to send a multicast to other hosts to check DAD even for LLA.
Ed/
-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: Monday, July 12, 2021 7:04 PM
To: Vasilenko Eduard <[email-masked]>; Philip Homburg <[email-masked]>; [email-masked]
Cc: Alexandre Petrescu <[email-masked]>
Subject: RE: on-link and off-link 

Pascal

> NBMA or P2MP are not supported by IPv6 anyway because it is not 
> possible to check LLA uniqueness - multicast does not work.
> The conceptual model of on-link is that a host can use neighbor 
> discovery to find an onlink neighbor. If the neighbor is not on-link 
> then traffic has to go (at least initially) through a default router.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 12 Jul 2021 16:25:18 +0000

Indeed

Which I read as "classical ND is not suited to these configurations" whereas RFC 8505 works just fine.

PVLANs are an illustration that the Woodstock thinking is not the safest thing and people may want more privacy and protection / isolation. This is true in SP / cable with PVLAN isolating modems, this is also true in an enterprise where zerotrust and SAVI are getting mind share. 

Keep safe,

Pascal

> From: Vasilenko Eduard <[email-masked]>
> Sent: lundi 12 juillet 2021 18:15
> To: Pascal Thubert (pthubert) <[email-masked]>; Philip Homburg <pch-
> [email-masked]>; [email-masked]
> It blocks not just native P2MP technology, It does break any filtering,
> like "PVLAN" or "WiFi isolation", Because if it is not possible to send a
> multicast to other hosts to check DAD even for LLA.
> Ed/
> To: Vasilenko Eduard <[email-masked]>; Philip Homburg <pch-
> [email-masked]>; [email-masked]
> So what IP considers a link and who belongs to a subnet (is constrained by
> but) does not need to match what the L2 sees, e.g., the L2 links (e.g., an
> ethernet wire or a radio range) and the L2 broadcast domains (e.g., a
> 802.1 bridged domain or a Wi-Fi ESS).

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 12 Jul 2021 18:57:59 +0000

Typically it's because EUI-64 has been widely implemented for use in SLAAC - not because having a default is the correct thing to do.

- Wes

On 7/12/21, 9:29 AM, "Alexandre Petrescu" <[email-masked]> wrote:

    Alex

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 12 Jul 2021 19:33:11 +0000

I agree that NS(DAD) for LLA has to be handled with care - and that's what we did with our NBMA link that's been working fine for tens of millions (probably hundreds of millions by now) of people for the past decade, which supports IPv6 fine by the way.  And yes, we implemented IPv6 multicast on that link too - everything has to be controlled by the hub site (think really big specialized hardware router) on an NBMA link, which is true for IPv4 as well.

- Wes

On 7/12/21, 11:41 AM, "ipv6 on behalf of Vasilenko Eduard" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 13 Jul 2021 07:37:17 +0000

TR-177 in general and annex B in detail elaborates DAD proxy for BNG. Some sort of filtering is mandatory for broadband telco services because of LI, billing - traffic should go through BNG.
I have not seen equivalent discussion in IETF.

IPv4 has additionally NHRP that was not extended to IPv6. NHRP was more popular then proxy for IPv4.
RFC 2333: "NHRP can be used in host-host, host-router and router-host  communications."
Eduard
-----Original Message-----
From: Wes Beebee (wbeebee) [mailto:[email-masked]] 
Sent: Monday, July 12, 2021 10:33 PM
To: Vasilenko Eduard <[email-masked]>; Philip Homburg <[email-masked]>; [email-masked]
Cc: Alexandre Petrescu <[email-masked]>
Subject: Re: on-link and off-link 

- Wes