Re: Route Information Options in Redirect Messages (updated)

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

At Tue, 31 Jan 2017 23:14:59 +0000,
"Templin, Fred L" <[e-mail]> wrote:

> An updated version of "Route Information Options in Redirect Messages" is now
> available (see below). This version addresses 6man list comments posted in the
> 1/9/2017 - 1/12/2017 timeframe, and re-aligns the work from intarea to 6man.
> It also expands on several aspects of the proposal that were not covered in the
> intarea draft. Please (re-)review and post comments to the list.

I've read the 01 version.  Here are my comments.

- general

  I'd like to understand why we need this extension.  And I'd like
  this document to explain it.  At least from the current content of
  the draft it's not clear to me.

- Section 1

   "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861][RFC2460]
   provides a Redirect function allowing routers to inform recipients of
   a better next hop on the link toward the destination.

  A minor point, but I don't understand why [RFC2460] is referenced
  here.  I actually don't see the need for it in this context.

- Section 3.2

   These Redirect messages may
   be either "solicited" (i.e., an ordinary Redirect) or "unsolicited"
   (i.e., a Redirect generated without waiting for a packet to arrive).

  If I understand RFC4861 correctly, the concept of "unsolicited
  redirect" (whether it contains RIO or not) didn't originally exist
  and is a new update in this document.  Am I right?  If so, I think
  it should clearly state this update in addition to the allowance of
  the use of RIO in redirects somewhere (probably in Section 1).  And,
  perhaps more important, I don't understand why this concept has been
  introduced.  Some background motivation/justification would be
  helpful.

- Section 3.2

   An unsolicited Redirect message includes a Destination Address and
   Redirected Header option that are either fabricated or derived from a
   remembered packet that was processed at an earlier time.
   Alternatively, the message could omit the Redirected Header option
   and/or set the Destination Address field to "::" (the IPv6
   unspecified address).  Such a message would still satisfy the message
   validation checks in Section 8.1 of [RFC4861].

  I suspect a fabricated or '::' Destination Address doesn't always
  work like a remembered one, since in that case the sending router is
  (at least relatively) less likely to be the first-hop router for the
  Destination Address for the receiving host.

- Section 3.3

   [...] Type "D" hosts
   process Redirect messages with RIO elements by updating
   [...] and 3) their routing tables per any RIO
   elements present.

  Does this mean prefixes in the RIO will be updated even if they
  don't match the Redirect's Destination Address?  If so, I think it's
  better to clarify that explicitly.  I also think that behavior may
  be debatable (it's probably related to the general comment of
  understanding why we need this extension).

- Section 3.3.1

  The discussion in this subsection is confusing to me.  Since a
  "router MUST NOT update its routing table upon receipt of a
  Redirect" (Section 8.2. of RFC4861), a straightforward
  interpretation of the following text would be that it violates or
  updates RFC4861:

   Such Type "D" hosts act like a host in
   terms of processing received Redirects and act like a router in terms
   of sending Redirects.

  But I guess it's actually talking about a hybrid host-router node,
  acting as a host and DHCPv6 PD client on an "external interface"
  while acting as a router for "an entourage of backend hosts" on
  internal interface(s).  I see the existence of such a hybrid node at
  least in practice (even if it's not officially defined in IETF
  documents), but I don't understand why we have to bother to mention
  it in this specification, since it doesn't seem to be specific to
  the "type D" host.

- Section 4

   The Redirect function and RIOs are widely deployed in IPv6
   implementations.

  This sentence could read as if the proposed extension is already
  widely deployed in implementations.  If the intent is to say that
  - the redirect function is widely deployed, and
  - RIOs are (also) widely deployed (which I'm not so sure about, but
    is probably true given Windows has implemented it).
  then I'd suggest making it clearer.  I don't have a specific
  suggestion, but perhaps stating these separately in separate
  sentences is an easy way to do it.

- Section 6

   "IPv6 Router Advertisement Guard" [RFC6105] ("RA Guard") describes a
   layer-2 filtering technique intended for network operators to use in
   [...]

  I don't understand the purpose of this paragraph, especially in the
  context of the Security Considerations section.  Does this sentence
  try to say that we could use the proposed extension in an
  environment where a legitimate router can't send an RA due to
  (perhaps misconfigured) RA guard?  That's probably true, but in that
  case we should solve this problem operationally, i.e., fix the
  configuration of RA guard rather than tweaking the protocol.  And
  that doesn't seem to be a topic of security considerations anyway.
  Or does this paragraph try to say something else?  In that case I
  totally misunderstand it, and I guess it will have to be fully
  rewritten unless I'm the only dumb person to understand it...

--
JINMEI, Tatuya