Subject: [v6ops] A thought on default routes

From: Fred Baker <[email-masked]>
Date: Thu, 8 Dec 2011 08:06:03 -0700

I'm looking at a presentation that Mark Townsley is giving, and he specifies a default route as ::/0. Yes, that's the prefix that RFC 5156 says should be used:

> 2.11.  Default Route
> 
>    ::/0 is the default unicast route address.

I have a problem. If I am describing generic route maps for BGP (what to announce, what to accept), I don't want to announce/accept as global unicast routes link-local, multicast, ULAs (except for specific ones I choose to), IPv4 addresses (::/80), or various not-yet-specified addresses - and all of those are included in ::/0 by definition, because it includes all addresses. I do want to include addresses that are in fact global (eg not ULA, which is a form of local) unicast addresses. There are a set of other addresses that are for the moment in limbo - we haven't really decided, but we expect that they will be allocated to IANA as unicast addresses eventually.

It seems that an operator wants to accept/announce the prefixes in 
  http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml

which (RFC 4147) is today 2000::/3. RFC 4147 is correct in saying that no implementation (no code embedded in a product) should make that assumption, but operationally it seems absolutely wise to assume that unicast addresses are in fact those that have been delegated as unicast addresses.

One prefix I would hope is *never* actually advertised as a default route is ::/0, because it includes routes that are in fact not global unicast routes.

First: operators, do you agree?

Second: is this something that should be stated somewhere, perhaps as an erratum to RFC 5156?

If I were to specify an erratum, I think it might say something like:

old:
> 2.11.  Default Route
> 
>    ::/0 is the default unicast route address.

new:
2.11.  Default Route

   ::/0 is the set of all IPv6 addresses. Operational default routes, as specified in [RFC4147], should include the addresses registered in the IANA registry iana-ipv6-unicast-address-assignments, but not include ULA, multicast, imported IPv4, or other special purpose routes.

---

From: Gert Doering <[email-masked]>
Date: Thu, 8 Dec 2011 16:29:12 +0100

Hi,

> First: operators, do you agree?

I don't feel that strongly about it - but something to keep in mind: the
"KISS" principle asks for *simple* approaches, and the most simple way
to specify a default aka "catch all" route is ::0/0.

In IPv4, we do 0.0.0.0/0, even if we know that it contains loopback,
multicast, and class E space.

Now, feel free to slap me for stating "we do it that way in IPv4" - but
it's the straightforward way...

Gert Doering
        -- Oper
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: "Mallette, Edwin" <[email-masked]>
Date: Thu, 8 Dec 2011 15:44:39 +0000

Fred,

My responses are in-line...

On 12/8/11 10:06 AM, "Fred Baker" <[email-masked]> wrote:

>I'm looking at a presentation that Mark Townsley is giving, and he
>specifies a default route as ::/0. Yes, that's the prefix that RFC 5156
>says should be used:
>
>> 2.11.  Default Route
>>
>I have a problem. If I am describing generic route maps for BGP (what to
>announce, what to accept), I don't want to announce/accept as global
>unicast routes link-local, multicast, ULAs (except for specific ones I
>choose to), IPv4 addresses (::/80), or various not-yet-specified
>addresses - and all of those are included in ::/0 by definition, because
>it includes all addresses. I do want to include addresses that are in
>fact global (eg not ULA, which is a form of local) unicast addresses.
>There are a set of other addresses that are for the moment in limbo - we
>haven't really decided, but we expect that they will be allocated to IANA
>as unicast addresses eventually.
>
>which (RFC 4147) is today 2000::/3. RFC 4147 is correct in saying that no
>implementation (no code embedded in a product) should make that
>assumption, but operationally it seems absolutely wise to assume that
>unicast addresses are in fact those that have been delegated as unicast
>addresses.
>
>One prefix I would hope is *never* actually advertised as a default route
>is ::/0, because it includes routes that are in fact not global unicast
>routes.
>
>

[EJM]  No.  The ::/0 default parallels much of what many of us do in the
IPv4 world.  Certainly within an AS I can think of a number of cases where
I would want to advertise ::/0 rather than having to manage and advertise
a number of individual prefixes to account for my Unicast default, my ULA
prefix "default", etc.  Across AS boundaries, I think I might agree with
you.  However it's certainly possible that in the future I might want to
advertise a default route between AS under my control just like I do for
IPv4 today.
>   ::/0 is the set of all IPv6 addresses. Operational default routes, as
>specified in [RFC4147], should include the addresses registered in the
>IANA registry iana-ipv6-unicast-address-assignments, but not include ULA,
>multicast, imported IPv4, or other special purpose routes.

[EJM] I'm not sure that I see the issue with the original text.  If you
want to provide completely informational text to remind operators that the
::/0 default includes ULA, multicast, imported IPv4, and other special
purpose routes, that's fine.  I don't see the need to add normative text
as I do plan to use ::/0 for operational simplicity just like I use
0.0.0.0/0 for IPv4.
>
>
>_______________________________________________
>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops

________________________________

CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 8 Dec 2011 10:57:16 -0500

<context target="RFC5156">that work started as a draft on providing more details/advice/... on how to filter IPv6 routes. but the "advice" got pushed back by some people. So the concensus was to make it light on the "advice" or on more details on bgp routing/filtering.
</context>
that explains I think a bit what you were looking for in the RFC but was not really there.

we might think of making a -bis or new with more data on filtering and include some discussions that you just wrote. Not sure an errata, since it starts to be more on changing the content than just fixing a little thing in the RFC (as I understand an errata should be)

Marc.

---

From: Fred Baker <[email-masked]>
Date: Thu, 8 Dec 2011 09:04:44 -0700

> as I do plan to use ::/0 for operational simplicity just like I use

...and as a result accept and announce ULAs by default.

OK, your call. Thanks for responding.

---

From: Gert Doering <[email-masked]>
Date: Thu, 8 Dec 2011 17:40:08 +0100

Hi,

> ...and as a result accept and announce ULAs by default.

I'm not sure how that is related.  Having a route for ::0/0 will 
*forward* packets destined to ULA space, that's true - but it doesn't
imply I would "accept and announce ULAs by default".

Now, my *prefix filters* are much more strict, and do not permit 
either ::/0 or 2000::/3.

So what specifically are you talking about...?  Routes, or filters?

Gert Doering
        -- NetMaster

---

From: Fred Baker <[email-masked]>
Date: Thu, 8 Dec 2011 10:13:02 -0700

> So what specifically are you talking about...?  Routes, or filters?

actually, both.

For filters, I think you and I agree that one should accept/announce only routes that make sense. How complex/restrictive that might get is cook's choice, but it should not include routes that don't make sense.

For routes, let's take a relatively simple example: I have a home/SOHO/whatever that has two routers in it, one of which (R1) is advertising a default route to the other (R2):

       -------------------------LAN 1
                  +--+
                  |R1|
                  +--+
       -------------------------LAN 2
                  +--+
                  |R2|
                  +--+
       -------------------------LAN 3

Some host on LAN 3 emits a packet to a random multicast address, one that is not advertised in multicast routing (if that is even turned on). Is the right result for R2 to obey ::/0 and unicast it to R1, or to drop it? If the advertised route were 2000::/3, the answer would be trivially obvious: there is no route to forward the packet using, so it is dropped. If the default route is ::/0, we now *also* need something else to exclude multicasts, which might be an inline test ("if it matches ... use the multicast route table"), a null route, or whatever.

Ditto ULAs, link-local, etc.

Not trying to make a federal case out of this, but I got to thinking about it, so here I am thinking out loud.

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 8 Dec 2011 10:20:29 -0800

>   ::/0 is the set of all IPv6 addresses. Operational default routes, as specified in [RFC4147], should include the addresses registered in the IANA registry iana-ipv6-unicast-address-assignments, b…

I am with Gert, KISS.

And, importantly, running code thinks a default route is ::/0

So, when i use this command to automagically have a router generate a
default route, it generates a ::/0

http://www.cisco.com/en/US/docs/routers/crs/software/crs_r4.0/routing/command/reference/rr40crs1book_chapter1.html#wp1835201429

"To cause a Border Gateway Protocol (BGP) speaker (the local router)
to send the default route 0.0.0.0/0 to a neighbor for use as a default
route, use the default-originate command in an appropriate
configuration mode. To disable this function, use the no form of this
command.
................The default-originate command does not require the
presence of the default route (0.0.0.0/0 for IPv4 or ::/0 for IPv6) in
the local router."

While i understand the intention of making the default route more
strict, i would rather avoid confusion on what a default route is.  A
default route, IMHO, says forward all unicast packets over to here.

CB

---

From: Havard Eidnes <[email-masked]>
Date: Thu, 08 Dec 2011 22:05:37 +0100 (CET)

> One prefix I would hope is *never* actually advertised as a default
> route is ::/0, because it includes routes that are in fact not
> global unicast routes.
>
>

No, I do not agree.

Why is announcing ::/0 problematical?

Is announcing 0.0.0.0/0 in IPv4 any more or less problematical?

Or more generally, why would running with the default route in your
network be problematical?  (Yes, there is and should only be one
default route, and you should not have to periodically look up in the
IANA registry to find "the default route this year".  Instigating such
a procedure is just asking, no, *begging* for widespread trouble.)

Regards,

- Håvard, who runs a "mostly edge" network

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 8 Dec 2011 13:17:43 -0800

> ...and as a result accept and announce ULAs by default.

Just as in IPv4 today we accept and announce RFC1918, multicast, and so on,
by default.

---

From: Daryl Tanner <[email-masked]>
Date: Thu, 8 Dec 2011 22:04:16 +0000

Hi Fred

> specified in [RFC4147], should include the addresses registered in the IANA
> registry iana-ipv6-unicast-address-assignments, but not include ULA,

I think this adds unnecessary complication.

The usage of the default route depends on the application - as an example:
- A host would want to direct anything non-local to its default gateway
- A LAN router would want to forward 'unknown' ULA via its default
- A border router would probably want to filter ULAs / multicast etc.

However. the catch-all is still ::0/0 for the default route. The router
should filter link-local, multicast etc as appropriate.

Daryl

---

From: Ole Troan <[email-masked]>
Date: Fri, 9 Dec 2011 08:11:59 +0100

Fred,

> Ditto ULAs, link-local, etc.

your argument would have made sense if this is how forwarding worked. but it isn't.
conceptually there are separate routing tables for each link-local scope. (without a default route.)
multicast is never forwarded using the unicast RIB.

ULA's would break in your case above without a default route (::/0).

cheers,
Ole

---

From: Gert Doering <[email-masked]>
Date: Fri, 9 Dec 2011 11:23:57 +0100

Hi,

On Thu, Dec 08, 2011 at 10:13:02AM -0700, Fred Baker wrote:
> Some host on LAN 3 emits a packet to a random multicast address,
> one that is not advertised in multicast routing (if that is even
> turned on). Is the right result for R2 to obey ::/0 and unicast it
> to R1, or to drop it? If the advertised route were 2000::/3, the
> answer would be trivially obvious: there is no route to forward the
> packet using, so it is dropped. If the default route is ::/0, we
> now *also* need something else to exclude multicasts, which might
> be an inline test ("if it matches ... use the multicast route
> table"), a null route, or whatever.
> 

I think the router needs special-case checks for link-local and multicast
space, no matter what.  Even if multicast routing isn't active, multicast
handling on lan links is still special, and cannot follow "normal unicast
routing".

So I can understand your thoughts, but I don't think implementations would
get any simpler if we mandated "do not use ::/0 for default, always use
2000::/3".

Historic trivia: some versions of the Linux kernel actually did this, 
requiring the default route to be specified as 2000::/3 if it was to be 
used for packet forwarding (as opposed to "host default" where ::/0 
worked just fine) - and that caused lots of extra confusion to admins...

Gert Doering
        -- operator