[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CPE router acting as host on its WAN interface (RE: draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC)
Hemant,
> -----Original Message-----
> From: Hemant Singh (shemant) [mailto:shemant@cisco.com]
> Sent: Tuesday, January 05, 2010 6:26 AM
> To: Templin, Fred L; Fred Baker (fred); v6ops@ops.ietf.org
> Cc: kurtis@kurtis.pp.se; rbonica@juniper.net
> Subject: RE: CPE router acting as host on its WAN interface (RE: draft-ietf-v6ops-ipv6-cpe-router-
> 03.txt WGLC)
>
>
> -----Original Message-----
> >From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
> Behalf Of Templin, Fred L
> >Sent: Monday, January 04, 2010 8:01 PM
> >To: Fred Baker (fred); v6ops@ops.ietf.org
> >Cc: kurtis@kurtis.pp.se; rbonica@juniper.net
> >Subject: CPE router acting as host on its WAN interface (RE:
> draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC)
>
> >Fred,
>
> >A concern I raised on the list a while back centers around
> >the behavior of the CPE router acting as a host on its WAN
> >interface per section 4.1:
>
> 6man hasn't even agreed with you as to what is the problem with your
> IsRouter flag discussion.
The IsRouter discussion was on this list (v6ops); not
the 6man list. Maybe you were talking about a different
discussion on the 6man list?
> > "When the router is attached to the WAN interface link it must act as
> > an IPv6 host for the purposes of stateless or stateful interface
> > address assignment ([RFC4862]/[RFC3315])."
>
> >and per WPD-3:
>
> > "WPD-3: Absent of other routing information the IPv6 CE router MUST
> > use Router Discovery as specified in [RFC4861] to discover a
> > default router and install a default route in its routing
> > table with the discovered router's address as the next-hop."
>
> >To my understanding, this behavior would involve the CPE
> >router sending Router Solicitation (RS) messages on its
> >WAN interface in order to receive Router Advertisement (RA)
> >messages. According to Section 6.2.6 of RFC4861, however:
>
> > "Whether or not a Source Link-Layer
> > Address option is provided, if a Neighbor Cache entry for the
> > (RS)'s sender exists (or is created) the entry's IsRouter flag
> > MUST be set to FALSE."
>
> >RFC4861 goes to some level of detail to specify the setting
> >of the IsRouter flag under various circumstances (including
> >the RS case), but it only says what actions should be taken
> >based on the flag as result of receiving Neighbor Advertisement
> >messages. Other actions based on the IsRouter flag setting do
> >not seem to be specified.
>
> Not quite. By default the IsRouter flag is set of FALSE. Also, see
> Appendix D of RFC 4861.
Yes, I include Appendix D in what I am meaning when I say
that "RFC4861 goes to some level of detail to specify the
setting of the IsRouter flag". But, it still doesn't say
what actions (if any) a host or router should take based
on the IsRouter setting.
The final sentence of Appendix D also says:
"In these cases, a subsequent Neighbor
Advertisement or Router Advertisement message will set
the correct IsRouter value."
but if the CPE will not send any RA messages over its
WAN interface then the NA is the only other option for
setting the correct IsRouter value.
> >In the linux kernel, it appears that the kernel will in some
> >circumstances garbage-collect FIB entries that have a nexthop
> >with the IsRouter flag set to FALSE. It is not clear what other
> >router implementations would do based on the IsRouter setting,
> >but it seems odd that the IsRouter flag in neighbor cache
> >entries corresponding to CPE routers would be set to FALSE
> >which in the linux case at least may lead to interoperability
> issues.
>
> What specific interoperability issues? What specific circumstances?
If a provider router garbage-collects a FIB entry because
it sees that IsRouter in the nexthop nbr cache entry is
FALSE, the FIB entry is gone and there is no route to the
CE router's prefixes. That is what I am meaning to say
regarding interoperability issues and circumstances.
> Further, since the FIB includes the Destination Cache, note that NUD
> purges entries in the Destination Cache. Garbage collection can remove
> an entry from the Default Router List - every entry in the Default
> Router List is a router. NUD can also purge entries in the Neighbor
> cache. If the CE Router sends an RS from its WAN interface, the router
> receiving such and RS sets the IsRouter flag for the CE Router entry to
> FALSE. So what? When the CE Router requests a delegated prefix, the
> delegating router will know the CE Router is requesting router.
First, the delegating router need not be co-resident on
the provider router that sends RA to the CE router; it
could be behind a chain of relays instead. Second, just
because the delegating router (and I guess also any
relays in the chain) come to know that the CE router is
a requesting router does not necessarily mean that the
provider router will know enough to reach into its kernel
and set the IsRouter flag in the nbr cache entry to TRUE.
Or, maybe that behavior is specified somewhere that I
didn't see?
I know about the RAAN option draft, and I can see that the
intent there is to have the relays in the chain come to know
about delegated prefixes so that they can inject them into
the routing system. But, that document does not seem to discuss
interactions with the IPv6 ND protocol, including the setting
of the IsRouter flag.
It also seems that DHCP prefix delegation is being used as a
routing protocol. The alternative is to use IPv6 ND RAs as a
routing protocol.
Fred
fred.l.templin@boeing.com
> Hemant