comments on draft-nward-ipv6-autoconfig-filtering-ethernet-00

[JINMEI Tatuya / 神明達哉 <Jinmei_Tatuya@isc.org>]

I've read this draft.  Here are some comments:

- Section 1, 1st para

   [...], and many hosts already listen for RA
   messages and then subsequent to receiving and RA message either
   configure addressing statelessly, or statefully with DHCPv6.

  I can't grammatically parse this clause, especially about "then
  subsequent to receiving and RA message".  Is this perhaps

   [...], and many hosts already listen for RA
   messages and then subsequent to receiving an RA message either
   configure addressing statelessly, or statefully with DHCPv6.

  or something?

- Section 2.1, in the table:
  s/Router;s/Router's/

   | Destination IPv6  | FF01::1 for unsolicited, an address in        |
   | Address           | FE80::/64 for solicited                       |

  s/FF01::1/FF02::1/

  "FE80::/64 for solicited" is certainly the typical case, but is not
  the only possibility.  The source of RS can be any unicast address
  (including) global, and the router can send a unicast RA to that
  address.

- Section 2.2, 1st para

   DHCPv6 reply messages SHOULD only be sent by DHCPv6 servers and
   relays, and so should only enter a switch from a port with a DHCPv6
   server or relay, and/or from a DHCPv6 server or relay's link-local
   IPv6 address or ethernet MAC address.

  This is not really correct either.  As far as I understand it,
  there's no restriction on the source address of a DHCPv6 reply
  message.  In particular, if the client and (off-link) server
  exchange unicast messages directly after the server allows it with
  the Server Unicast Option, the source address of a DHCPv6 reply from
  a server should be non-link-local.

- Section 2.2, in the table

   | Destination IPv6      | An address in FE80::/64                   |

  This is also not (always) true.  One counter example is the above
  case where a client and an off-link server exchange messages
  directly.  Even if the reply is sent from an on-link node (always
  the case for a relay), RFC3315 doesn't require the destination
  address is a link-local address.

   | UDP source port       | 547                                       |

  I believe this is also not always true.  RFC3315 only requires the
  server to listen to port 547, but doesn't say the server use the
  same source port for messages it generates.

Admittedly, these cases are rare exceptions, so if we propose
something strict concentrating on typical scenarios, that may make
sense.  But in that case we should at least note that it's not a
protocol level requirement and there can be exception that was broken
by the proposed filtering rule.


- Section 3, 1st para

   An ethernet switch MUST be able to be configured to filter Router
   Advertisement and DHCPv6 reply messages under one or both of the
   following conditions:

  This MUST sounds too strong to me in a general statement like this.
  Personally, I wouldn't use any RFC2119 keyword here, and IMO more
  clarification is needed about in which case this requirement is
  mandated if we keep the MUST.

- Section 3.1

   It may be desirable for a switch to only transmit Router Solicitation
   and DHCPv6 request messages out a port if it is configured as a port
   having a router, DHCPv6 server or relay.  Comment is sought for this.

  At least other DHCPv6 message that client can send must be allowed,
  i.e, all but Reply and Reconfigure.  Relay-forward should also be
  allowed.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.