Subject: DISCUSS: draft-ietf-ipv6-unique-local-addr-06.txt

From: Alex Zinin <[email-masked]>
Date: Wed, 13 Oct 2004 18:46:57 -0700

1. It would be useful to give a definition of a "site", keeping the routing
   aspects in mind.

2. Section 4 "Routing"

>    Any router that is used between sites must be configured to filter
>    out any incoming or outgoing Local IPv6 unicast routes.  The
>    exception to this is if specific /48 or longer IPv6 local unicast
>    routes have been configured to allow for inter-site communication.

>    If BGP is being used at the site border with an ISP, the default BGP
>    configuration must be set to to keep any Local IPv6 address prefixes
>    from being advertised outside of the site or for these prefixes to be
>    learned from another site.  The exception to this is if there are
>    specific /48 or longer routes created for one or more Local IPv6
>    prefixes.

In the above statement, is it assumed that BGP has visibility to site
boundaries, or that it is always used for inter-site connectivity and never for
intra-site? The reason for the question is that requiring default BGP behavior
to be as described above calls for site awareness and implementation change. If
the real intention is that BGP should be _manually_ _configured_ to filter out
local prefixes, the text needs to be changed.

It should be noted that if an link state IGP (OSPF/IS-IS) is used for routing
between sites, which is a possibility in enterprise networks, a single site
should be contained within a single IGP domain or area, as prefix distribution
within a link-state area cannot be controlled.

Section 6.0

>    Site border routers should install a "reject" route for the Local
>    IPv6 prefix FC00::/7.  This will ensure that packets with Local IPv6
>    destination addresses will not be forwarded outside of the site via a
>    default route.  Site border routers should respond with the
>    appropriate ICMPv6 Destination Unreachable message to inform the
>    source that the packet was not forwarded [ICMPV6].  This feedback is
>    important to avoid transport protocol timeouts.
> 
>    Site border routers and firewalls should not forward any packets with
>    Local IPv6 source or destination addresses outside of the site unless
>    they have been explicitly configured with routing information about
>    specific /48 or longer Local IPv6 prefixes.  The default behavior of
>    these devices should be to install a "reject" route for these
>    prefixes.  Site border routers should respond with the appropriate
>    ICMPv6 Destination Unreachable message to inform the source that the
>    packet was not forwarded.

There's an overlap between the two paras above. The first para covers the
destination address check. The second tries to cover both destination and
source.

First, I'd like to understand exactly what "outside of the site" means in this
section. Does it mean a non-FC00::/7 IPv6 dst address, or a FC00::/7 address
with another global-ID, or both?

Second, do you realize that checking the source address will require changes to
the router's forwarding algorithm compared to how global addresses are handled?

Third, it is a current operational practice to disable ICMP unreachables for
reject routes to avoid ICMP storms cause by infected machines' scanning the
network. I suggest we change it to something like "MAY send, MUST be
configurable, and MUST be off by default".

From rtg-dir (Radia):

The document should be more clear about what the desired behavior is for the
case where two or more sites are connected together.

-- 
Alex
http://www.psg.com/~zinin

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 18 Oct 2004 13:30:00 +0200

--On onsdag, oktober 13, 2004 18:46:57 -0700 Alex Zinin <[email-masked]> 
wrote:

> boundaries, or that it is always used for inter-site connectivity and
> never for intra-site? The reason for the question is that requiring
> default BGP behavior to be as described above calls for site awareness
> and implementation change. If the real intention is that BGP should be
> _manually_ _configured_ to filter out local prefixes, the text needs to
> be changed.

does the term "default BGP configuration" make sense?

---

From: Alex Zinin <[email-masked]>
Date: Wed, 20 Oct 2004 16:15:50 -0400

Harald,

  Generally, yes, it does. We have configurable parameters in many protocols,
  and in many cases we define the default value for those, which I would
  consider the default configuration that implicitly defines the default
  behavior--normally something that should work reasonably well without further
  human intervention. In the case below, however, the BGP implementation will
  need to be aware of the sites, something that we don't have now. Since the
  document does not define what a site is, it is difficult to assess what
  changes (if any) to the BGP implementations would be required.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 21 Oct 2004 08:21:52 +0200

--On onsdag, oktober 20, 2004 16:15:50 -0400 Alex Zinin <[email-masked]> 
wrote:

> Harald,
>
>   Generally, yes, it does. We have configurable parameters in many
> protocols,   and in many cases we define the default value for those,
> which I would   consider the default configuration that implicitly
> defines the default   behavior--normally something that should work
> reasonably well without further   human intervention. In the case below,
> however, the BGP implementation will   need to be aware of the sites,
> something that we don't have now. Since the   document does not define
> what a site is, it is difficult to assess what   changes (if any) to the
> BGP implementations would be required.

A site is whatever I define it to be :-)

but the "default" configuration here is, I believe, a default configuration 
of address prefix filters. I don't know if routers come with such a thing; 
my impression has been that there is enough policy here that it's more 
sensible to start BGP configs with a clean slate. But I could be wrong.

                    Harald

---

From: Alex Zinin <[email-masked]>
Date: Fri, 22 Oct 2004 17:12:19 -0700

Harald,

  In my follow-up with Bob, I asked them to clearly separate router
  implementation requirements from operational routing guidelines.
  This should help.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 23 Oct 2004 10:58:09 +0200

>   implementation requirements from operational routing guidelines.

Yes, it should.

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 25 Oct 2004 21:45:10 -0400

Hi Alex,

>   implementation requirements from operational routing guidelines.

If I understand what you are asking for, I don't think that this is a 
good thing to do...

The line between routing implementation and routing operation is not 
well-defined, and where the line is drawn differs based on the type 
of router and its intended use.

For example, it would make sense for a home gateway to include 
filtering for the ULA address prefix to/from its external port, 
because home gateways have a well-defined external port, and they 
generally include a fairly conservative default configuration. 
However, it would make sense for a router intended for internal 
enterprise networks _not_ to include a filter for these addresses. 
While a router intended for enterprise-edge deployment (if there is 
such a specialized device) could contain a default configuration that 
filters local addresses at the edge.  It is my understanding that 
carrier-class routers come with very little (if any) default routing 
configuration and pretty much everything is left to policy.

So, I don't think that a hard line exists today between router 
implementation requirements and operational guidelines, and I don't 
think that it makes sense to introduce one in this document.

Thoughts?

Margaret

---

From: Alex Zinin <[email-masked]>
Date: Tue, 26 Oct 2004 18:10:19 +0400

Margaret,

  Such a hard line does exist and the spec needs to be very clear about what
  goes where.

  The implementation requirements define pieces of code that need to be changed
  or added on _every_ router when ULA support is added. Operational ones define
  how those pieces or assumed to be already implemented functionality are
  expected to be configured and used.

  In your example, a home gateway is a special case of a router with a lot of
  things configured by default. Every vendor is free to choose the default
  configuration based on the expected deployment scenarios. This does not change
  where the line goes.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 26 Oct 2004 07:51:53 -0700

Alex,

>   Such a hard line does exist and the spec needs to be very clear about what

Could you explain this view?  I don't understand this "hard line".

>   expected to be configured and used.

I don't think any code is required in an IPv6 router to be implemented to 
support ULA addresses.  Everything in the ULA specification can be done via 
configuration.  [I am assuming the router has the ability to configure 
source address filters].  Of course, a router vendor could decide to build 
special support in the code (e.g., to make it easy to turn on ULA filtering 
on a set of interfaces), or perhaps to add it to an ASIC forwarding engine 
to get the best filtering performance.  But I don't see it as being 
required and these implementation decisions are a vendor decision.

>   configuration based on the expected deployment scenarios. This does not 

Please define the line.  I don't understand the distinction you are making.

Thanks,
Bob

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 26 Oct 2004 13:21:38 -0400

Hi Alex,

>   expected to be configured and used.

If this is the line, then the answer is that ULAs do not introduce 
any requirements for router implementations.

Unlike the previous site-local addresses that required that (at least 
some) routers be able to be configured as site border routers (SBRs) 
and required that SBRs maintain separate routing information for 
multiple overlapping site-local prefixes, ULAs do not introduce any 
implementation requirements for routers (even the ones on 
organizational/site boundaries) and will work fine with IPv6 routers 
that are already deployed.

There are some operational requirements for organizations that use 
these things.  They need to decide how far they want the routing 
information for each local prefix to propagate and should filter 
routes for these addresses and the packets that are addresses to/from 
these addresses at those borders.

>   configuration based on the expected deployment scenarios. This 

Makes sense.  Sorry for misunderstanding your previous message.

Margaret

---

From: Alex Zinin <[email-masked]>
Date: Sat, 30 Oct 2004 09:43:35 +0400

Margaret,

  Yes, this makes sense to me. As I asked in my message to Bob, can we change
  the text in the draft accordingly?

  Thanks.

---

From: Alex Zinin <[email-masked]>
Date: Sat, 30 Oct 2004 09:42:07 +0400

Bob,

> Could you explain this view?  I don't understand this "hard line".

Sure. As I tried to explain, if all routers are supposed to do something
automatically once a ULA is configured without any additional configuration from
the administrator, such functionality would fall into router implementation
requirements category. For instance, if you wanted the site border routers to
automatically start filtering out packets using ULAs and crossing the site
border as part of the standard forwarding function (as described in the
addressing architecture document, for example), we would need to go several
steps further and think about what exactly a site is, and how routers are
supposed to know when a packet is leaving a site (e.g. per-interface site
knowledge, with checks during pkt fwd'ing). The same is applicable to the
routing part--if you wanted site border routers to automatically filter out
routes between sites, we would need to think about the same sort of things as
above, how they work together, and how that works with routing protocols.

Operational requirements give guidelines to administrator about how to configure
routers when the technology is deployed. For instance, we could suggest that
"site border routers should be configured with access lists (packet filters)
disallowing packets that use ULAs as the source or destination addresses to
cross the boundary of a site".

> source address filters].

Can we change the text to be clearer that normal routing and forwarding
functionality is not changed and that these are configuration/operational
guidelines?

> Of course, a router vendor could decide to build 

Of course.

Alex

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 1 Nov 2004 14:36:45 -0500

Yes, I think that we could change the text to make this clearer. 
I'll let Bob make specific suggestions.

Margaret

---

From: Bob Hinden <[email-masked]>
Date: Thu, 04 Nov 2004 17:10:22 -0800

Alex,

>above, how they work together, and how that works with routing protocols.

OK that makes sense.  Since ULAs do not require code changes, I think we 
can change the text to make it clearer that we are describing operational 
guidelines.

Had we defined ULAs to, for example, not use longest match prefix lookups, 
then there would be a big impact on router functionality.  But, of course, 
we didn't do that :-)

>functionality is not changed and that these are configuration/operational

Yes, that is very doable.  How about the following:

Adding a new section 4, titled "Operational Guidelines" and then make 
current sections 4-10 be subsections.  For example:

    4.0 Operational Guidelines
      4.1 Routing.........................................................7
      4.2 Renumbering and Site Merging....................................8
      4.3 Site Border Router and Firewall Packet Filtering................8
      4.4 DNS Issues......................................................9
      4.5 Application and Higher Level Protocol Issues....................9
      4.6 Use of Local IPv6 Addresses for Local Communications............9
      4.7 Use of Local IPv6 Addresses with VPNs..........................10

Then add the following text between 4.0 and 4.1:

     The guidelines in this section do not require any change to the
     normal routing and forwarding functionality in an IPv6 host or 
router.  These
     are configuration and operational usage guidelines.

In addition, I think there are few places in the text in these sections 
where "should be configured" could be added to make this clearer.

> > required and these implementation decisions are a vendor decision.

Please let us know what you think.

Bob

---

From: Alex Zinin <[email-masked]>
Date: Sat, 6 Nov 2004 00:53:44 -0800

Bob,

 I think we're completely in sync. Changes you suggest below would address
 my concerns.

 Thanks!

---

From: Bob Hinden <[email-masked]>
Date: Sun, 07 Nov 2004 07:45:52 -0800

Alex,

>  I think we're completely in sync. Changes you suggest below would address

Great!  I will update the draft once the window opens again.

Bob

> >> >>   or added on _every_ router when ULA support is added. Operational 
> ones
> >> >> define