Subject: v6ops-routing-guidelines ID

From: Danny McPherson <[email-masked]>
Date: Mon, 19 Mar 2007 03:50:09 -0600

[resend]

As stated at the microphone, my particular concern regarding
this draft is that making routing recommendations like this result
in both control plane and data plane issues when new address
prefixes are allocated.  We've seen this many times over the
past few years, resulting in extremely fragmented policy in ISP
networks.

2.5.  Global Unicast

    The global unicast routes (2000::/3) [RFC4291] may be advertised in
    an IGP or EGP.

    A minimal EGP routing policy should filter out routes that exceed a
    maximum length.  Determining the maximum length of a global Internet
    route is outside the scope of this document.

    A finer EGP routing policy may use only the allocated address space
    from IANA to registries as specified in
    http://www.iana.org/assignments/ipv6-unicast-address-assignments.
    This would result in better filtering since the non-allocated
    prefixes will be filtered out.

Again as we've seen, this leads to fragmented reachability
issues when filters aren't updated and new prefixes are allocated.
This manifests itself as both a control AND data path issue.  I.e.,
if I'm not accepting reachability information for a given prefix then
as a matter of policy why would I accept packets sourced from or
destined to that address space?  And then something new is
allocated and there's a lag there between when it's used and
policies are updated to accommodate the allocations.

    An even finer EGP routing policy may use only the assigned address
    space from registries to providers as available in the registries
    databases.  This would result in the best filtering since the non-
    assigned prefixes will be filtered out.  However, this requires the
    synchronization of the filters with the registries databases.

This is all that we should be recommending, if anything, IMO,
and note that the previous paragraph requires precisely the same
amount of "synchronization".

Also, the entire 2.5 section is in conflict with the abstract, in
particular the "It does not discuss operational or policy issues
such as the maximum length of prefixes to filter." statement.

I agree with Pekka in that simply likening and scoping this
document such as RFC 3330 Special-Use IPv4 Addresses would
be a much better model for the IETF to follow, then perhaps a
routing and control plane discussion in a deployment considerations
section that touches on what operators might want to consider
wrt operational policies and associated caveats.  Perhaps even a
BCP 38 reference is in order?

Also, what is the intention of this document?  BCP, at best,
or perhaps even informational?  I would think the latter like
RFC 3330.  It's current status is currently labeled as "Standards
Track", which I suspect is a bit off base.

Some other nits:

2.6.  Default Route

    The default unicast route (::) may be advertised in an IGP.  It must
    not be advertised in an EGP unless it has been requested by the
    recipient.

How does one request a default route?

2.8.  Unknown addresses

    Any non listed address above must not be advertised and should be
    filtered out.  Future work might reserve additional address space  
for
    protocol use which might require specific routing guidelines.  The
    reader should refer to newer versions of the normative references in
    this document to verify the existence of newer protocol address
    space.

Where would operators find such a list if we're recommending they
filter these address spaces?

In section 3.0 in addition to the BCP 84 reference, a BCP 38
reference should be included.

In summary, I would much rather decouple routing guidelines
(which these are more of "don't route guidelines") from any ID
document explicitly and provide the relevant IANA and RIR
policies, and subsequent to that, IRR, etc..

I would much rather see a document here akin to RFC 3330.

I do believe there would be utility in a general routing
guidelines document, but see the scope as quite a bit
larger than this, and it's home would perhaps be GROW
rather than here.  A cross-WG review from GROW of this
document if it continues would likely be a good thing as
well.

-danny

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 19 Mar 2007 12:06:48 +0100

- thanks for comments
- partial response below. more later.

> Track", which I suspect is a bit off base.

my fault. I found that too when doing the ID-nits.  Intent was  
informational or BCP.  will be fixed in -02.

> How does one request a default route?

well, that was the suggestion text from someone who provided comment  
on the previous version. The intent of the suggestion was to avoid  
the use of "downstream" which is ambiguous.  Do you have any  
suggestion for text?

>    filtered out.  Future work might reserve additional address  
> space for

it currently says newer versions of the normative references (that is  
one way one can do and find).
Any suggestion?

> reference should be included.

ok. agreed. will add.

Marc.

---

From: Danny McPherson <[email-masked]>
Date: Mon, 19 Mar 2007 06:54:27 -0600

> - partial response below. more later.

Thanks for the prompt reply, I look forward to your
responses on the outstanding comments as well.

> well, that was the suggestion text from someone who provided  
> comment on the previous version. The intent of the suggestion was  
> to avoid the use of "downstream" which is ambiguous.  Do you have  
> any suggestion for text?

I might be able too suggest something if I understand
what the goal of such a statement would be.  I don't
recall anything similar along these lines in IPv4 (I do know
how IPv4 default routes are 'advertised' and why), and I'm
not sure how it's unique here.  Note also that one's "routing
policy" could specify that any prefix be interpreted as
default.

> it currently says newer versions of the normative references (that  
> is one way one can do and find).
> Any suggestion?

My point was that if we're asking folks to follow these routing
guidelines and possibly generate and deploy policy based on
them, they'll need a source for the input from which they could.
One would think IANA and the RIRs would be a good start, but
the IRRs and similar sources would be ideal - though require
much more explicit policy expressions.

-danny

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 19 Mar 2007 14:03:22 +0100

Le 07-03-19 à 13:54, Danny McPherson a écrit :

> what the goal of such a statement would be.

may be this "default route" topic is too obvious. The starting point  
of this section (actually the whole document) was RFC2772.  So I took  
RFC2772, remove everything no more relevant, and then update.  That  
is the basic reason why this section exist.
But I'm fine to remove that whole default route section, if it is the  
concensus.

> I don't
> not sure how it's unique here.

nothing unique to v6.

> Note also that one's "routing

well, there is some text about this in 2.5  section.

Marc.

---

From: Kevin Loch <[email-masked]>
Date: Mon, 19 Mar 2007 10:05:44 -0400

> How does one request a default route?

On a sales form, in an email or on the phone while the session is being
configured.

- Kevin

---

From: Danny McPherson <[email-masked]>
Date: Mon, 19 Mar 2007 10:11:00 -0600

> well, there is some text about this in 2.5  section.

There's an IANA reference, not any direct RIR one, or any
IRR one.  Ultimately, it should be based on IRRish policy,
but there's a bootstrap issue there.

The earlier point about this was that if someone downloads
the IANA file and defines policy based on the availability of
the prefix for allocations needs to synchronize them
periodically (frequently) or things WILL break.

We've seen problems with filtering based on IANA bogons
recently with IPv4's 96 & 120, for example.

-danny

---

From: "Durand, Alain" <[email-masked]>
Date: Mon, 19 Mar 2007 12:36:23 -0400

As promised this morning, I'm reviewing
draft-ietf-v6ops-routing-guidelines-01.txt

First, as it stands, I do not see much difference with RFC2772, section
3:

   3. Common Rules for the 6bone....................................  3
       3.1 Link-local prefixes......................................  3
       3.2 Site-local prefixes......................................  4
       3.3 Loopback and unspecified prefixes........................  5
       3.4 Multicast prefixes.......................................  5
       3.5 IPv4 compatible prefixes.................................  5
       3.6 IPv4-mapped prefixes.....................................  6
       3.7 Default routes...........................................  6
       3.8 Yet undefined unicast prefixes...........................  6
       3.9 Inter-site links.........................................  6
       3.10 6to4 Prefixes...........................................  7
       3.11 Aggregation & advertisement issues......................  7

draft-ietf-v6ops-routing-guidelines-01.txt:
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Address Types . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Node-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3
     2.2.  IPv4-Mapped Addresses . . . . . . . . . . . . . . . . . . . 3
     2.3.  Link-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3
     2.4.  Site-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3
     2.5.  Global Unicast  . . . . . . . . . . . . . . . . . . . . . . 3
       2.5.1.  Documentation Prefix  . . . . . . . . . . . . . . . . . 4
       2.5.2.  6to4  . . . . . . . . . . . . . . . . . . . . . . . . . 4
       2.5.3.  Teredo  . . . . . . . . . . . . . . . . . . . . . . . . 4
       2.5.4.  6bone . . . . . . . . . . . . . . . . . . . . . . . . . 4
     2.6.  Default Route . . . . . . . . . . . . . . . . . . . . . . . 4
     2.7.  Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 5
     2.8.  Unknown addresses . . . . . . . . . . . . . . . . . . . . . 5

More important, I have a fundamental issue with this draft that I
already
mentionned in Montreal IETF. From the IETF66 meeting minutes:

>  Alain: The IETF is not the network police, and we can't say
>  anything on filtering policy. What we can do is say that these are
>  the trade-offs.

In its current form, with lots of 'must not be advertized' & similar
statement,
I cannot support this draft moving forward.

I would much favor a document listing 'special case IPv6 addresses'
and 'things to think about when routing them', explaning
what can go wrong if those prefixes are routed but specifically
NOT MAKING RECOMMENDATIONS to tell anybody how to run his network.

  - Alain.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 19 Mar 2007 18:52:43 +0200 (EET)

> I would much favor a document listing 'special case IPv6 addresses' 
...

I'd support this approach.  I believe that the operators should be 
clueful enough to figure out which special-case prefixes they want to 
filter and how without the IETF having to give recommendations; 
something like the summary table of Section 3 of RFC3330 (and possibly 
some supporting background like Section 2) might be sufficient.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Stig Venaas <[email-masked]>
Date: Mon, 19 Mar 2007 17:57:08 +0100

> NOT MAKING RECOMMENDATIONS to tell anybody how to run his network.

I would also favour this,

Stig

---

From: "Ryon Zhang" <[email-masked]>
Date: Mon, 19 Mar 2007 18:43:23 +0100

I think this states a basic routing filtering guideline, which means it's up
to date itself and  maybe  modified according to  operators' specific
requirements.  So maybe the Intended Status can be changed to
"Informational".

Ryon

---

From: Colm MacCarthaigh <[email-masked]>
Date: Tue, 20 Mar 2007 03:19:59 +0000

>    not be advertised in an EGP unless it has been requested by the

Is this really wise anyway? Firstly, it should probably be "::/0"
, :: is a whole different route on most systems, but that's just
anal pedantry.

But is using :: as a default unicast route wise? Why not 2000::/3?
If you use 2000::/3 then many common errantly routed packets 
start to fail RPF checks more quickly, examples include the many
types of packet that have :: as an on-the-wire source address
(e.g. MLD) that ocasionally end up being routed when they shouldn't
be, and of course spoofed and corrupted sources outside of 2000::/3.

That said, I don't have any statistics on whether any vendors have
particular optimisations for the ::/0 route or if it's a typical
depedency for multicast forwarding. (though here it says unicast route).

I can understand ::/0 being in an IGP, because the AS might have
internal non-globally routed unicast packets, but why would it be a good
idea for ::/0 to be advertised in an EGP at all. Why forward packets we
know to be globally unroutable?

-- 
Colm MacCárthaigh                        Public Key: [email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 Mar 2007 13:48:34 +0100

> , :: is a whole different route on most systems, but that's just

Right, :: is the unspecified IPv6 address, ::/0 is a prefix  
encompassing the entire IPv6 address space.

> But is using :: as a default unicast route wise? Why not 2000::/3?

Because then it wouldn't be a default route but a "global unicast  
space as we know it today" route.

I had a look at the draft and I'm afraid that it doesn't really  
provide much useful information. Sure, there is lots of stuff that  
people shouldn't put in their routing protocol, but most of this  
stuff happens automatically anyway and nearly all of the rest can be  
summarized as "only advertise routes that you've received from an ISP  
or registry for that purpose".

---

From: Joe Abley <[email-masked]>
Date: Tue, 20 Mar 2007 18:40:35 +0100

On 19-Mar-2007, at 17:52, Pekka Savola wrote:

> clueful enough to figure out which special-case prefixes they want  
> to filter and how without the IETF having to give recommendations;  
> something like the summary table of Section 3 of RFC3330 (and  
> possibly some supporting background like Section 2) might be  
> sufficient.

As I think I mentioned at the microphone yesterday, I also like this  
approach.

Joe

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 20 Mar 2007 23:02:03 +0100

After discussion with wg chairs, I have written and sent another  
draft based on the RFC3330-for-ipv6 idea (RFC3330 was the starting  
point instead of RFC2772) to the internet-draft repository. You  
should see the announcement as soon as it reopens. So that way, wg  
can compare both approaches.  when published, I will send my own  
summary of diffs.

Marc.

Le 07-03-20 à 18:40, Joe Abley a écrit :

> As I think I mentioned at the microphone yesterday, I also like  
> this approach.
>
>
> Joe
>
>

-----
IPv6 book: Migrating to IPv6, Wiley, 2006, http://www.ipv6book.ca