Re: [dhcwg] WGLC for draft-ietf-dhc-topo-conf-03.txt - Respond by Oct 13, 2014

[神明達哉 <[e-mail]>]

At Fri, 09 Jan 2015 21:22:45 +0100,
Tomek Mrugalski <[e-mail]> wrote:

> > - My question on this sentence seems to still remain:
> >
> >    [...]  It is
> >    up to administrator to make sure that the interface-id is unique
> >    within his administrative domain.
> That was a valid concern. While the interface-id may be used for link
> selection if it's unique in an administrative domain, there's no
> guarantee that it will be. The text now says:
>
>    If the interface-id is unique within an
>    administrative domain, the interface-id value may be used to select
>    appropriate subnet.  As there is no guarantee for the uniqueness
>    ([RFC3315] only mandates the interface-id to be unique within a
>    single relay agent context), it is up to the administrator to check
>    whether the relay agents deployed use unique interface-id values.  If
>    they aren't, Interface-id cannot be used to determine client's point
>    of attachment.

(Note: below, I only talk about a relay agent that forwards DHCPv6
message from clients, not another relay agent, for simplicity).

First off, just wondering: where in RFC3315 does it "mandate the
interface-id to be unique within a single relay agent context"?
Although that's a valid understanding (and it in fact matches mine) of
what interface-id's should be by definition, I don't see any explicit
requirement in RFC3315 about that.

Secondly, I suspect it's super rare that interface-id's are unique
among all relay agents in a specific DHCPv6 service domain, so the
text still looks quite awkward to me.

Thirdly, on re-reading relevant documents, I now wonder in which case
a relay agent ends up (necessarily) including the interface-id option
in the first place.  RFC 3315 Section 20.1.1 states:

   If the relay agent received the message to be relayed from a client,
   the relay agent places a global or site-scoped address with a prefix
   assigned to the link on which the client should be assigned an
   address in the link-address field. [...]

   If the relay agent cannot use the address in the link-address field
   to identify the interface through which the response to the client
   will be relayed, the relay agent MUST include an Interface-id option
   (see section 22.18) in the Relay-forward message.

Now that site-local unicast addresses have been deprecated, this means
the relay agent always specifies a global address for the link-address
field (although there's no RFC2119 keyword here).  In which case could
the relay agent not "use the address to identify the interface
through which the response to the client will be relayed", then?  I
can imagine one scenario in the era of RFC3315 (although I don't know
that was the original intent of the RFC): the relay agent is located
at a site-border, receiving messages from DHCPv 6 clients from
different sites, and some links to different sites are associated with
the same site-local prefix (the relay agent could still disambiguate
the interface using some node-local "interface-id").  But, with the
deprecation of unicast site-local addresses we don't have to think
about such cases anymore.

Depending on the answer to these points, I may be able to propose text
that would address my concern.  Right now, though, I feel I'm now even
more confused.

> > - Regarding this text:
> >
> >    In all cases, then, the DHCP server will have a link-identifying IP
> >    address, and in some cases it may also have a link-specific
> >    identifier (e.g.  Interface-Id Option or Link Address Option defined
> >    in Section 5 of [RFC6977]).  It should be noted that there is no
> >    guarantee that the link-specific identifier will be unique outside
> >    the scope of the link-identifying IP address.
> >
> >   My question on the second sentence seems to be still open.  Pasting
> >   it: 'The second sentence is also not really clear to me...what does
> >   "outside the scope of the link-identifying IP address" mean?
> >   Usually "the link-identifying IP address" should be global, so there
> >   is basically no "outside the scope" of it in the first place.'
> Maybe scope is a poor choice of words here, but I don't know how to find
> a better way to explain it. What we (I think Ted is the original author
> of that part) wanted to say here is that the link-specific identifier on
> its own is not that useful, only a tuple of IP address + link-specific
> identifier is useful. Added the following clarification:
>
>    For example, link-specific indentifier of
>    "eth0" for a relay agent with IPv4 address 192.0.2.1 means something
>    different than "eth0" for a relay agent with address 192.0.2.123.
>
> Hopefully it will be sufficient. If it isn't, it would be great if you
> could offer a better text.

Sorry, but this is even more confusing to me...I don't even understand
why it now talks about IPv4 addresses.

This is also related to the previous point, btw: with the deprecation
of unicast site-local addresses, the link-identifying IP (which I
interpret means the innermost link-address field of the relay forward
message) should be always global, and should always be unique all over
the world, no?

BTW, the proposed new text seems to have some editorial issues:
- s/indentifier/identifier/
- I guess "there" should have been removed from: "It should be noted
  that there the link-specific identifier is unique..."

Finally: one other thing I noticed as I write this response: in the
same Section (3.2):

   For completeless, we also mention an uncommon, but valid case, where
   relay agents set link-local address in the link-address field in
   relayed Relay-forward messages.

I don't think this is a valid case, since RFC 3315 clearly states the
link-address field is a global or (now-deprecated) site-local address
as noted above (again, even though there's no RFC2119 keyword here).

--
JINMEI, Tatuya