Hi Bob,
> -----Original Message-----
> From: Bob Hinden [mailto:[email protected]]
> Sent: Tuesday, December 01, 2009 5:38 PM
> To: Templin, Fred L
> Cc: Bob Hinden; Thomas Narten; [email protected]
> Subject: Re: New draft on "Stub Router Advertisements in IPv6
> NeighborDiscovery"
>
> Fred,
>
> In my personal view, I think you need to really investigate what can be done
> with OSPF. There is a
> lot of experience with it and how it scales and there is real experience with
> OSPF on real NBMA
> networks. It is an existing well known solution.
OK; clearly the consensus based on what you and others are
saying is that when OSPF (or some other IGP) can be used, it
should be used. That would not be inconsistent with what I
have written in the other documents I have been working on,
but it definitely needs to be called out more explicitly as
the preferred method for navigating an NBMA link. I can fix
that, and I will note these discussions for historic record.
> If the real focus of this is large deployments of ISATAP across thousands of
> routers, I think you
> need to provide some evidence that this is a real problem in some real
> deployment. Also, why would
> someone want to use ISATAP in an environment like that? Native or point to
> point tunnels seems a lot
> simpler to me.
I want to be able to turn up IPv6 in an IPv4-only network in
a manner that is as consistent as possible with the principles
identified in the Introduction of RFC1955:
- No Changes to Hosts
- No Changes to Most Routers
- No New Routing Protocols
- No New Internet Protocols
- No Translation of Addresses in Packets
- Reduces the Routing Table Size in All Routers
- Uses the Current Internet Address Structure
I believe this can be done using an update to ISATAP that
enables router-to-router tunneling.
> With my w.g. chair hat on: If you are trying to turn ND into a routing
> protocol (for ISATAP), then
> then is very likely out of scope for the 6man w.g. This is not maintenance.
OK, I accept this and I think it answers my question as to
whether work on using ND as a routing protocol should be
addressed in a 6man document or in an "IPv6-over-(foo)"
document. It seems like it should be the latter if any
further work on this is to be done.
But looking strictly from a maintenance perspective as a
separate question, there still seems to be a class of devices
that are routers (i.e., that forward packets not addressed to
themselves) but that should either not send RAs at all or
should be very careful about the information they include
in RAs so as not to be inconsistent with the information
advertised by other routers on the link. The diagram I
cited in an earlier message shows a case where this is
true, and applies not only to NBMA links but also to any
other sort of shared link (multicast or non-multicast).
This question has come up in MANET discussions also, to
name one other venue.
Can we have further discussion in 6man as to when it is
appropriate for routers to send RAs and when it is not?
Thanks - Fred
[email protected]
> Regards,
> Bob
>
>
>
> On Dec 1, 2009, at 5:09 PM, Templin, Fred L wrote:
>
> > Bob,
> >
> >> -----Original Message-----
> >> From: Bob Hinden [mailto:[email protected]]
> >> Sent: Tuesday, December 01, 2009 4:14 PM
> >> To: Templin, Fred L
> >> Cc: Bob Hinden; Thomas Narten; [email protected]
> >> Subject: Re: New draft on "Stub Router Advertisements in IPv6
> >> NeighborDiscovery"
> >>
> >> Fred,
> >>
> >> Why not just use OSPF? It already supports NBMA networks and is widely
> >> supported by existing
> >> routers.
> >
> > On the sorts of NBMA links I am concerned with (ISATAP being
> > the primary example), it may be impractical to involve great
> > multitudes of routers in a single OSPF instance. For instance,
> > in ISATAP applied to ISP networks it might be possible for
> > hundreds or thousands of CPE routers that don't know about
> > each other to engage in a routing protocol instance with a
> > set of well-known default routers in the provider network
> > and thereby discover one another. But, it might not scale
> > well, and it might not allow for secure exchanges between
> > CPE routers that must consult with 3rd party trust anchors
> > within the ISP network before they can communicate with each
> > other directly.
> >
> >> Adding complexity to ND to solve what sounds like a routing problem seems
> >> to me like the
> >> wrong way to go.
> >
> > It is solving a routing problem without a routing protocol
> > by taking the ISATAP host-to-router model and extending it
> > to apply also to router-to-router. It leverages the concept
> > of the ISATAP link and the operation of IPv6 Neighbor
> > Discovery over the ISATAP link.
> >
> > Router-to-router tunneling is something that was left as
> > out-of-scope when RFCs 4214 and 5214 were published; I am
> > now working to address router-to-router tunneling through
> > a new document that would update RFC5214. Part of this is
> > how routing would work, and the other part is how ingress
> > filtering can be asserted so that packets that come from
> > a router that is not authorized to send them can be dropped.
> >
> > Thanks - Fred
> > [email protected]
> >
> >> Bob
> >>
> >>
> >> On Dec 1, 2009, at 3:45 PM, Templin, Fred L wrote:
> >>
> >>> Hi Thomas,
> >>>
> >>>> -----Original Message-----
> >>>> From: Thomas Narten [mailto:[email protected]]
> >>>> Sent: Tuesday, December 01, 2009 1:54 PM
> >>>> To: Templin, Fred L
> >>>> Cc: [email protected]
> >>>> Subject: Re: New draft on "Stub Router Advertisements in IPv6
> >>>> NeighborDiscovery"
> >>>>
> >>>> Hi Fred.
> >>>>
> >>>> the picture is a start...
> >>>
> >>> OK.
> >>>
> >>>> "Templin, Fred L" <[email protected]> writes:
> >>>>
> >>>>> http://osprey67.com/stub-router.pdf
> >>>>
> >>>>> In this picture, the link I am concerned with is labeled
> >>>>> "NBMA Link" in the diagram.
> >>>>
> >>>> Please add an indication for what a typical "site" is. Are all of the
> >>>> stub networks considered part of the same site (i.e., same company,
> >>>> same house, etc.)?
> >>>
> >>> In my picture, each stub network is a separate site.
> >>> The NBMA link and all of its attached devices is also
> >>> a separate site, so the provider-facing interfaces of
> >>> all of the stub routers in the diagram are connected
> >>> to the same site. (This is not to say that stub
> >>> network "sites" cannot be multi-homed; they certainly
> >>> can, but the drawing does not show examples of that
> >>> in order to avoid excessive clutter.)
> >>>
> >>>> Also, you show "stub network 1", 2, 3, .etc.
> >>>>
> >>>> What is the internal structure of those networks (or does it matter)?
> >>>
> >>> It doesn't matter.
> >>>
> >>>> In particular, there are presumably multiple links present in a stub
> >>>> network. Are there only "normal" routers internally?
> >>>
> >>> Normal routers and links, yes. But, each stub network
> >>> could itself contain multiple internal NBMA links which
> >>> would appear to be sites within themselves (or, "sites-
> >>> within-sites"). Each of those "sub-sites" would have
> >>> a set of default routers and a set of routers that
> >>> appear as stubs within that site. In other words,
> >>> the model is recursive.
> >>>
> >>>> Can a "stub" router only exist on the NBMA link?
> >>>
> >>> Do you mean, are NBMA links the only examples where
> >>> one would find stub routers? I don't think so, but
> >>> NBMA links are peculiar and may present challenges
> >>> to ordinary routing protocols that are not as
> >>> prevalent on "ordinary" links.
> >>>
> >>>> Can you provide a specific example of the kind of link technology you
> >>>> are thinking of for the NBMA link? Is this DSL/Cable/ATM? Or just a
> >>>> hypothetical NBMA link? And who runs the NBMA link? Is this not a link
> >>>> operated by the Provider?
> >>>
> >>> One example is an ISP network that connects multitudes
> >>> of CPE routers (i.e., stub routers) with a finite
> >>> collection of gateways via IP-in-IP tunneling. ISATAP
> >>> is an example NBMA link type that could be used in
> >>> such networks.
> >>>
> >>>> I see there are "hosts" on the NMBA link. Can you provide examples of
> >>>> what kind of hosts? (I guess I really don't understand the deployment
> >>>> model you are assuming here... i.e., why wouldn't the NBMA link only
> >>>> have routers on it, with all hosts being behind a router.)
> >>>
> >>> Take ISATAP for example. The hosts configure tunnel
> >>> endpoints that connect to the ISATAP "link". Any
> >>> device that supports ISATAP can connect to the
> >>> NBMA link in this fashion, e.g., if there is no
> >>> way for the host to connect behind an "ordinary"
> >>> router.
> >>>
> >>>>> As you can see, there are stub networks connected to the link by
> >>>>> stub routers, and default routers that connect the link to provider
> >>>>> networks (which then connect to the Internet in some way). The link
> >>>>> is intentionally shown as two segments joined together by "..." to
> >>>>> show that it can be arbitrarily large and in some cases may contain
> >>>>> hundreds, thousands, or even more stub routers and stub networks.
> >>>>
> >>>> OK.
> >>>>
> >>>>>> From the diagram, only those routers labeled "default router"
> >>>>> should advertise default router lifetimes, M&O flags, PIOs,
> >>>>> and other RA information that provides operating parameters
> >>>>> for the link. If the routers labeled "stub router" also
> >>>>> advertised those kinds of parameters, then any hosts labeled
> >>>>> "host on NBMA link" would incorrectly update their link
> >>>>> parameters. As a simple example, if a router labeled "stub
> >>>>> router" advertised a non-zero default router lifetime in
> >>>>> an RA that was heard by a host labeled "host on NBMA link",
> >>>>> then the host would incorrectly configure a default route
> >>>>> that points to a stub network.
> >>>>
> >>>> OK. I understand this.
> >>>>
> >>>> That said, my first reactions would be:
> >>>>
> >>>> 1) is this a real deployment scenario? Who is setting up a network
> >>>> like this? Maybe they shouldn't do this and there are better
> >>>> approaches...
> >>>
> >>> There are a wide variety of use cases; 'draft-rangers-russert'
> >>> lists many of them.
> >>>
> >>>> 2) So what if the default route (on some hosts) points to the wrong
> >>>> thing, the stub router will presumably send a redirect for any
> >>>> traffic it is relaying, and the host will update its cache and from
> >>>> that point forward things are fine. Perhaps not "optimal" in a pure
> >>>> sense, but I certainly don't see this is as so broken a fix is
> >>>> needed... At least not without really understanding who is
> >>>> operating a network like this...
> >>>
> >>> I'm afraid I didn't understand this; the hosts will discover
> >>> default routes in the same way that the stub routers will.
> >>> ISATAP is an example of a mechanism that provides for hosts
> >>> to discover the unicast addresses of default routers.
> >>>
> >>> Fred
> >>> [email protected]
> >>>
> >>>> Thomas
> >>> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list
> >>> [email protected]
> >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
