Re: Fwd: Re: note from the iesg plenary

[Pekka Savola <pekkas@netcore.fi>]

I've added ipng to Cc: list as this has never been discussed there, and is
IMO mostly ipng-stuff.

On Fri, 10 Aug 2001, Margaret Wasserman wrote:
> >>Basically, I have four issues:
> >>
> >>         (1) Boundaries for regular route lookups.
> >>         (2) Site-local routing.
> >>         (3) Anycast routing.
> >>         (4) Routing table MIBs.
> >>
> >>(1)  The current addressing architecture defines all routable
> >>unicast addresses to include a 64-bit identifier.  Does that mean
> >>that it is reasonable for a router to only look at the first 64
> >>bits when making a routing decision?  Or should routers still treat
> >>these addresses as CIDR-like?

I think this was discussed very recently in 'prefix length used by
backbone routers' thread in multi6.  I'm not sure if all issues raised
here were brought up there.

> >>(2) Site-local routing is particularly confusing on a site-border router.
> >>I don't know if anyone has really implemented one, but it seems likely
> >>that it will need to have multiple routing tables (one global table
> >>and one per attached site).  Even an intra-site router may need two
> >>conceptual routing tables (one global, one site).
[snip]

Why would there be a need for two routing tables?  It might help, but I
don't see it as strictly necessary.

Wouldn't "practically" some equivalent of an IPv6 access list, blocking
site-local addresses from spreading outside of the site and in the site be
sufficient?

Also, all routing EGP protocols should have route-map's or equivalent to
eliminate the possible spread of site-local, and link-local, address
announcements.

It's legal to use different AS numbers inside the site (e.g. one or two
primary ones and some from private space), the default behaviour perhaps
should be:

 1) in eBGP (or anything between two AS numbers), filter site-local
announcements by default
 2) if extra keyword "same-site" is used even with different AS's, this
would not be done.

> >>(3) IPv6 anycast is substantially different from the anycast hacks
> >>currently used in IPv4.  One big difference:  a global IPv6 anycast
> >>address would (probably?) not appear to be inside of anyone's AS.
> >>I don't know if this causes problems, as I haven't had time to look
> >>at how OSPF would handle a host route injection for a router outside
> >>the AS.

Another huge difference (from usage point of view): IPv6 anycast address
MUST not be used as a source address.

I doubt host route injection will work due to "martian" filtering of
/128's, or other such routes.  What will work, is the similar thing as it
is done with IPv4 anycast:

Consider:

6to4 IPv4 anycast prefix is 192.88.99.0/24.
6to4 IPv4 anycast address is 192.88.99.1.

If someone injected 192.88.99.1, that would surely be filtered.

But as IPv6 anycast is defined the same as IPv4 anycast, you can just
inject routes to to some /48, /64, etc. networks -- no different than
current route injections.

(btw, nobody is advertising 6to4 anycast prefix in DFZ yet.  Shows the
current ipv4 anycast deployment rate mentioned in ngtrans at IETF51 wrt.
isatap discovery IMO.. :-)

> >>However, the IPv4 stuff has only been tried with BGP.  Do we know for
> >>sure that the OSPF tree will converge if it thinks that one host is
> >>actually located at two different places in the topology?  Maybe this
> >>would just work -- I don't know OSPF well enough to know for sure
> >>without closely reviewing the spec (or maybe trying it).

We cannot be sure.  That is, if OSPF costs (or other protocols' metrics)
to different anycast advertisements are equal, there will be
load-balancing.  But then again, this might be designed behaviour (for
unicast, probably not for anycast) too.

By designing the site topology properly, and adjusting the last-hop (ie.
router to host providing anycast service; this might not always be doable
if routers themselves act as anycast servers) OSPF costs by adding big
values there, e.g. "500" or "1000" so there would be no overlap no matter
what, this should converge quite nicely.

This is a policy issue.  One might want to (in intra-site policy) either
(or some others):

 - select the closest anycast server (ospf cost should not be adjusted,
loadbalancing would be considered a feature)
 - select always the default anycast server if it's responding, if not,
select a different one (preferring the service with ospf cost)

> >>(4) The current IPv6 routing table MIBs are based on the IPv4
> >>routing MIBs.  It isn't clear if they will be able to properly
> >>handle IPv6 routing tables, as they may be different.  Once we
> >>figure out the architecture and conceptual datastructures, I will
> >>closely review the MIBs to see if they match.

As you know, Bill Fenner is revising these.  Now's the time...

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords