Re: [Softwires] Last Call: <draft-ietf-softwire-4rd-08.txt> (IPv4 Residual Deployment via IPv6 - a Stateless Solution (4rd)) to Experimental RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



So this is a little bit embarrassing given that I just did my AD review of this document, but the way the DHCP options were done violates the recommendation in the DHCPv6 Option Guidelines document (RFC 7227) in that it uses suboption codes for the 4RD_MAP_RULE and 4RD_NON_MAP_RULE options, instead of treating OPTION_4RD as an encapsulating option, and the other two options as encapsulated options (see section 9 of RFC 7227). 

   o  One DHCPv6 option codes TBD1 for OPTION_4RD of Section 4.9
      respectively (to be added to section 24.3 of [RFC3315].  Suboption
      values of 4RD_MAP_RULE (0) and 4RD_NON_MAP_RULE (1) should also be
      recorded into the DHCPv6 option code space.

Also, the suboption configuration is expressed as a server requirement, when it's actually an operational requirement:

OLD:
   o  4rd rule suboptions: the 4RD DHCPv6 option SHOULD contain at least
      one 4RD_MAP_RULE suboption and maximum one 4RD_NON_MAP_RULE
      suboption. the length of suboptions in octets
NEW:
   o  4rd rule suboptions: the 4RD DHCPv6 option contains at least
      one 4RD_MAP_RULE suboption and maximum one 4RD_NON_MAP_RULE
      suboption. Since DHCP servers normally send whatever options
      the operator configures, operators should be advised to
      configure these options appropriately.   DHCP servers MAY
      check to see that the configuration follows these rules and
      notify the operator in an implementation-dependent manner
      if the settings for these options aren't valid.






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]