[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New (-02) version of IPv6 CPE Router draft is available for review
David,
Please see in line between <hs> and </hs>.
-----Original Message-----
From: David Miles [mailto:davidm@thetiger.com]
Sent: Friday, July 18, 2008 12:16 AM
To: Hemant Singh (shemant)
Cc: v6ops WG
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for
review
Hemant and Wes,
Some comments on draft-02:
- The un-numbered model doesn't require a loopback interface
<hs>
It does. You may be behind checking your emails on this thread. Please
read ample evidence given for this one.
</hs>
- ULA addresses generation per RFC4193 may not be appropriate for CPE as
it requires time of day and is a one-time algorithm. I think we may need
to suggest a new random algorithm that is consistent with the one in RFC
4193 and does not require time of day. We should also point out that a
ULA prefix should be consistent across reloads and there must be some
method by which the user can regenerate or otherwise specify their
desired ULA prefix. Finally ULA is a 48-bit prefix.
<hs>
Hmm, ULA is restricted to one home, so what are the odds of ULA clashing
for one single home/SOHO premise since number of devices in the home may
be 256 or even 500 or so. The only way my ULA is visible to my
neighbor's home is if the CPE Router includes a WLAN. But two different
homes have different wireless SSID, so even then if the ULA clashes with
my neighbor's, it's not a clash. I do grant folks that fact that both
myself and my neighbor may be lazy people and we both use the default
SSID shipped with the WLAN of the CPE Router. But anyhow, how many
clients exists in the home that the algorithm in RFC4193 is not good.
For 100 connections, RFC4193 has this probability of collision.
100 4.54*10^-09
</hs>
- I think we should add a line that says traffic with a ULA source
address should not be forwarded out the WAN interface, rather than
noting you could use user-configured ACL.
<hs>
All Internet RFC's mention filtering of ULA traffic at the edge. In
that vein our use of ACL is appropriate. Anyhow, this is a minor point
we can look into later.
</hs>
- Seeing you mention DAD on the WAN interface, you may also want to add
joining the solicited-node MC group via MLD per RFC 4861/2.
<hs>
Disagree with the idea. We mention DAD in the draft only because for
some links like PPP, the draft needs to point out that DAD will not be
invoked for unicast addresses. Your suggestion is one detail too many.
</hs>
- Suggest you use RIPng terminology rather than RIPv6
<hs>
Agreed. Thanks.
</hs>
- The IPv6 over PPP and softwire sections makes no mention of WAN
interface address assignment other than IPv6CP (interface-ID). Should we
support both numbered and unnumbered models on PPP links?
<hs>
Yes. PPP links also get their link-local address as per RFC5070. Then
just like other networks that don't use PPP, even PPP link will use
SLAAC or DHCPv6 to acquire a global IPv6 address. I have also said, we
need to update the Unnumbered section to also include assigning the
Loopback interface a global IPv6 address from the IA_PD obtained by the
Loopback interface. I can add such text to the PPP section.
</hs>
- Section 7: IPv6 Data forwarding should reference the Default Routers
List and the creation of the default route based on this.
<hs>
No. We will define our router in terms of our own conceptual variables
for routing. Default Routers List is a ND conceptual variable.
</hs>
As you've covered off cascading routers we also need to consider how to
route traffic to them (assuming they will in turn populate their default
router list with the root CPE). This suggests the DHCPv6 server in the
CPE must be able to trigger route updates based on active leases.
<hs>
Once we say that RIPng may be used in the home, that is enough for
routing information to flow from home's downstream routers to the next
upstream router in the cascade. We will consider adding text to the
Cascading section to say RIPng may be used in the home. The DHCPv6
server suggestion is so that the IA_PD can be sub-delegated downstream
in the cascade, not for route updates!
I have snipped out the rest of your email because I will reply to the
snipped lot in another email. I wanted to get this reply out first.
</hs>
Hemant