[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: new version of the CPE Rtr draft is ready for review
Teemu,
Thanks very much for the review. I and Wes
discussed your comments and here are our responses back in
line between <hs> </hs>.
Hi,
I like this document a lot, and really look forward to get
this forward.
Few comments:
- 5.4. says that CPE router has failed DHCPv6 address
acquisition if IA_PD option is not included in ADVERTISE/REPLY in stateful
DHCPv6 case. Now considering case where a CPE router is embedded into
mobile host that is attaching to different networks, some of which may
mandate DHCPv6 use and some of which don't: if the mobile host always asks for
IA_PD, but sometimes doesn't get it (due differencies in network policies),
isn't the address acquisition process still successful for the host itself,
but just not for CPE router function of the host? I mean could this section
be clarified to state that in such case the address acquisition is only
partially succesful? And perhaps that in such case the CPE router can configure
the IPv6 address for itself and at the same time initiate
other-but-less-preferred means for providing Internet connectivity to LAN side,
such as fall-back to IPv4-only CPE router functionality, bridging, (NATting
between ULA and global IPv6 address...), or doing ND
proxying?
<hs>
Good catch.
This section missed the zero-LAN case. We can modify text in this section
to say something like "the CPE Router software knows its running in a zero-LAN
hardware device and in such a case of zero-LAN hardware, if an IA_PD is not
asked for by the CPE Router, nor does a DHCPv6 response received by the CPE
Router includes the IA_PD Option, then there is no error
deemed.
</hs>
- Is there a reason why ND Proxy (RFC4389) is not
mentioned? Because it is of experimental category?
<hs>
Partial reason. But we
have not found a need for the CPE Router to support ND Proxy just yet. If
any deployment still thinks that the CPE Router MUST support an ND Proxy, please
contact us and we will evaluate the deployment and the
need.
</hs>
- 5.5.2. one scenario for WAN initialization before
LAN is that LAN side is not initialized at all without external host first
connecting to CPE router by some technology. Again cellular use case: a mobile
has always-on WAN connectivity for usual uses (VoIP/email/MMS/browsing) and a
host (say PC) initiates WLAN/Bluetooth/USB/whatever connection to a mobile only
much later than initial WAN connection was created. In such case the trigger for
requesting IA_PD would be initialization of LAN side physical interface (e.g.
triggering of Bluetooth PAN profile), as asking for IA_PD at the moment of WAN
initialization would unnecessarily reserve prefixes by hosts never utilizing
those.
<hs>
We
can modify this section's 1st para, 2nd line to change from
[After the IPv6
address configuration for WAN interface is completed, the CPE Router configures
IPv6 address for LAN interface(s).]
to
[After the IPv6
address configuration for WAN interface is completed, the CPE Router may
configure IPv6 address(es) for any LAN interface(s).]
Further,
in the 2nd paragraph, a portion of the 1st sentence of the same section
changes from
[Once IPv6
address configuration of the LAN interface(s) is complete,
]
to
[When and if
IPv6 address configuration of the LAN interface(s) completes,
]
</hs>
- 5.6. IPv6 over Ethernet and PPP are not the only
existing technologies and possibly more are coming, Maybe this chapter should be
generalized? Examples of other technologies are:
* RFC5121 Transmission of IPv6 via the IPv6
Convergence Sublayer over IEEE 802.16 Networks
* RFC3574 Transition Scenarios for 3GPP
Networks (which is somewhat incomplete now as 3GPP has made some rather
significant changes to bearer concepts since 2003)
<hs>
We need to think
about this one.
<.hs>
- Could CPE router utilize RFC5006 on LAN and/or WAN
interfaces?
<hs>
We personally have not accepted this RFC and it's also an
experimental one. See more below against your DHCPV6
server comments. Again, unless a deal-breaking need is found where
this RFC MUST be supported by the CPE Router, we will skip this RFC in our
document.
</hs>
- Is stateless DHCPv6 server or DHCPv6 relay SHOULD
or MUST for CPE router to provide hosts in LAN with access to other
configuration parameters available from service provider's DHCPv6
server? I.e. not just for reasons described in chapter 6.
<hs>
Yes, at least
a stateless DHCPv6 server is needed to pass Service Provider options
to the LAN device(s). We think section 5.7 can be renamed to "DHCPv6
Server" and then we can discuss both stateless and stateful DHCPv6 servers in
the section.
<hs>
<hs>
Wes is on top of
this section. He will read your draft pointer above and we will reply
a little later on this one.
</hs>
- As several transition mechanisms are being worked on, the
8.6 should perhaps mention that DS-Lite is not the only mechanisms that may
cause this chapter to be updated.
<hs>
We do say in this
section that several proposals are out there. However, we should probably
mention more than just DS-Lite.
</hs>
If you wish, I can contribute text from cellular
perspectives.
<hs>
If you are coming to IETF
73, let's get together and discuss this. We are presenting this draft in
v6ops.
</hs>
Thanks.
Kind
Regards.
Hemant &
Wes.
Best regards,
Teemu
Thanks.
Hemant &
Wes