[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)



Ole,

> -----Original Message-----
> From: ichiroumakino@gmail.com [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan
> Sent: Wednesday, January 06, 2010 12:00 PM
> To: Templin, Fred L
> Cc: Fred Baker; v6ops@ops.ietf.org; 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)
> 
> Fred,
> 
> the IsRouter flag only has value to a host, so that it can detect that
> its default router is changing state from a router to a host. in this
> scenario which is really a router-to-router link I cannot see any
> problem with the service provider end getting the flag wrong. it is
> after all not used for anything on a routed interface.

Based on what I see in RFC4861, any interface that
maintains a neighbor cache (host or router) also manages
the IsRouter flag. 
 
> if an implementation deletes neighbor entries on a routed interface
> based on a change in this flag, then that's a bug.

It doesn't delete neighbor entries; it deletes FIB entries
(i.e., routes) that have a nexthop with IsRouter set to FALSE.

Fred
fred.l.templin@boeing.com

> cheers,
> Ole
> 
> On Tue, Jan 5, 2010 at 2:00 AM, Templin, Fred L
> <Fred.L.Templin@boeing.com> wrote:
> > 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:
> >
> >  "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.
> >
> > 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.
> >
> > As a result, it might be worth reconsidering whether it is
> > appropriate for the CPE router to send an RS which might
> > confuse other routers into thinking it is a host.
> >
> > Fred
> > fred.l.templin@boeing.com
> >
> >> -----Original Message-----
> >> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker
> >> Sent: Monday, January 04, 2010 7:45 AM
> >> To: v6ops@ops.ietf.org
> >> Cc: kurtis@kurtis.pp.se; rbonica@juniper.net
> >> Subject: draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC
> >>
> >> This is to initiate a two week working group last call of draft-ietf-
> >> v6ops-ipv6-cpe-router-03.txt. Please read it now. If you find nits
> >> (spelling errors, minor suggested wording changes, etc), comment to
> >> the authors; if you find greater issues, such as disagreeing with a
> >> statement or finding additional issues that need to be addressed,
> >> please post your comments to the list.
> >>
> >> We are looking specifically for comments on the importance of the
> >> document as well as its content. If you have read the document and
> >> believe it to be of operational utility, that is also an important
> >> comment to make.
> >>
> >>
> >>
> >>
> >> On Dec 18, 2009, at 2:45 AM, internet-drafts@ietf.org wrote:
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> >> directories.
> >> This draft is a work item of the IPv6 Operations Working Group of the
> >> IETF.
> >>
> >>
> >>       Title           : Basic Requirements for IPv6 Customer Edge Routers
> >>       Author(s)       : H. Singh, et al.
> >>       Filename        : draft-ietf-v6ops-ipv6-cpe-router-03.txt
> >>       Pages           : 14
> >>       Date            : 2009-12-18
> >>
> >> This document specifies requirements for an IPv6 Customer Edge (CE)
> >> router.  Specifically, the current version of this document focuses
> >> on the provisioning of an IPv6 CE router and the provisioning of IPv6
> >> hosts attached to it.
> >>
> >> Status of this Memo
> >>
> >> This Internet-Draft is submitted to IETF in full conformance with the
> >> provisions of BCP 78 and BCP 79.
> >>
> >> Internet-Drafts are working documents of the Internet Engineering
> >> Task Force (IETF), its areas, and its working groups.  Note that
> >> other groups may also distribute working documents as Internet-
> >> Drafts.
> >>
> >> Internet-Drafts are draft documents valid for a maximum of six months
> >> and may be updated, replaced, or obsoleted by other documents at any
> >> time.  It is inappropriate to use Internet-Drafts as reference
> >> material or to cite them other than as "work in progress."
> >>
> >> The list of current Internet-Drafts can be accessed at
> >> http://www.ietf.org/ietf/1id-abstracts.txt.
> >>
> >> The list of Internet-Draft Shadow Directories can be accessed at
> >> http://www.ietf.org/shadow.html.
> >>
> >> This Internet-Draft will expire on June 21, 2010.
> >>
> >> Copyright Notice
> >>
> >> Copyright (c) 2009 IETF Trust and the persons identified as the
> >> document authors.  All rights reserved.
> >>
> >> This document is subject to BCP 78 and the IETF Trust's Legal
> >> Provisions Relating to IETF Documents
> >> (http://trustee.ietf.org/license-info) in effect on the date of
> >> publication of this document.  Please review these documents
> >> carefully, as they describe your rights and restrictions with respect
> >> to this document.  Code Components extracted from this document must
> >> include Simplified BSD License text as described in Section 4.e of
> >> the Trust Legal Provisions and are provided without warranty as
> >> described in the BSD License.
> >>
> >> A URL for this Internet-Draft is:
> >> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-cpe-router-03.txt
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >> Below is the data which will enable a MIME compliant mail reader
> >> implementation to automatically retrieve the ASCII version of the
> >> Internet-Draft.
> >> <mime-attachment>_______________________________________________
> >> I-D-Announce mailing list
> >> I-D-Announce@ietf.org
> >> https://www.ietf.org/mailman/listinfo/i-d-announce
> >> Internet-Draft directories: http://www.ietf.org/shadow.html
> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>
> >> http://www.ipinc.net/IPv4.GIF
> >>
> >
> >
> >