Subject: Re: (ngtrans) NUD over configured tunnels

From: Sowmini Varadhan <[email-masked]>
Date: Wed, 17 Nov 1999 09:46:36 -0500 (EST)

>To: Erik Nordmark <[email-masked]>
>
> In your previous mail you wrote:
>
>   > For the purpose of  Neighbor-Discovery (specifically, NUD),
>   > do bidirectional configured tunnels have a link-layer address?
>   
>   Since it is a pt-pt link there is no use sending around link-layer addresses
>   in ND messages.
>   
>=> I believe this is the good argument.

Yes, I agree as well. 

However,  RFC 2461 divides links into "those that have link-layer addresses"
and "those that don't have link layer addresses" with the receipt of
a unique link-layer address being required to make transitions
like {INCOMPLETE} -> {STALE, REACHABLE}.

So, since configured tunnels do have link-layer addresses, even though
it's somewhat superfluous to send the link-layer address option (are there
situations where a "link-layer address change" can occur on a configured
tunnel endpoint?) maybe draft-ietf-ngtrans-mech-04.txt should clarify things 
around this issue.

>   What do implementations do today?
>   
>=> ignore link-layer at receiving side, don't add link-layer at the
>sending side.

This is also true of our implementation.

>=> all junk things, for instance redirects with strange link-layer
>addresses are filtered out by sanity checks: no problem.
>
>   I suspect the MUST NOT will be too strong.
>
>=> I agree, there is no interoperability problem then MUST is too strong.
>
>   	An implementation SHOULD (or SHOULD NOT?) send such link-layer address 
>   	options.
>
>=> SHOULD NOT!

Well, the problem with SHOULD/SHOULD NOT is that it's not clear what
the option (esp. the padding) looks like when the sender chooses to
send the option. Which is why I picked the "MUST".

If we use "SHOULD NOT"  (NOT, since, as Erik pointed out, the link-layer
endpoints are usually pre-determined for pt-pt links), could we define 
the layout of the option in the spec as well?

Thanks,
Sowmini