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

Re: draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC



Dan,

thanks for extensive comments!

[removed DNS comment. as I have nothing to add. I'd really like a consensus coming out of v6ops/behave for any new or different CPE requirements]

> Section 3.1 should additionally mention that an end-network
> IPv4 CPE that incorporates a NAT also incorporates a DHCPv4 
> server.  The inclusion of a DHCP server in the CPE is implied, 
> but should be explicitly stated.  The DHCP server in the CPE 
> allows the in-home network to be self-sufficient (for IP 
> addressing, if not naming).
> 
> This is relevant to IPv6 because, I have been told, ULAs
> provide a similar "LAN only" address.  This should be
> mentioned or a pointer to how hosts inside the home should
> use ULAs mentioned.  We do not want streaming between an
> in-home NAS and an in-home television to rely on the
> WAN link's availability.  This is mentioned (insufficiently)
> in Section 4.2 and some of the L-* requirements.

agree. added your proposed text in section 3.1

> The definition of Service Provider is "a company that ...",
> which precludes non-companies such as, for example, a University 
> offering service to students in University housing.  Is that intentional?

<t hangText="Service Provider">an entity that provides
          access to the Internet. In this document, a Service Provider
          specifically offers Internet access using IPv6, and may also
          offer IPv4 Internet access. The Service Provider can provide
          such access over a variety of different transport methods
          such as DSL, cable, wireless, and others.</t>

is the above text any better? "entity" is quite fluffy, but what can you do...

> Many of the enumerated requirements contain multiple "MUSTs" or "SHOULDs".
> This makes things complicated, because a vendor (or a customer) cannot say,
> for example, "we comply with all of RFCxyz, except L-5" because L-5 contains
> three MUSTs and one SHOULD.  Taking L-5 as an example, I suggest changing
> from:
> 
> OLD:
>   L-5:   The IPv6 CE router MUST assign a separate /64 from its
>          delegated prefix (and ULA prefix if configured to provide ULA
>          addressing) for each of its LAN interfaces.  The IPV6 CE
>          router MUST make the interface an advertising interface
>          according to [RFC4861].  In router advertisements messages,
>          the Prefix Information Option's A/L-bits MUST be set to 1 by
>          default; the A/L bits setting SHOULD be user configurable.
> NEW:
>   L-5:   a. The IPv6 CE router MUST assign a separate /64 from its 
>             delegated prefix (and ULA prefix if configured to 
>             provide ULA addressing) for each of its LAN interfaces.
>          b. The IPV6 CE router MUST make the interface an advertising 
>             interface according to [RFC4861].  
>          c. In router advertisements messages, the Prefix Information 
>             Option's A/L-bits MUST be set to 1 by default; 
>          d. the A/L bits setting SHOULD be user configurable.
> 
> 
> This would allow a vendor (or a customer) to say "we comply with all of
> RFCxyz, except L-5c and L5-d".


I agree with this suggestion.

Best regards,
Ole