Subject: Fwd: I-D ACTION:draft-wasserman-ipv6-sl-impact-00.txt

From: Margaret Wasserman <[email-masked]>
Date: Fri, 20 Dec 2002 08:10:53 -0500

FYI --

Margaret

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : The Impact of Site-Local Addressing in IPv6
>         Author(s)       : M. Wasserman
>         Filename        : draft-wasserman-ipv6-sl-impact-00.txt
>         Pages           : 0
>         Date            : 2002-12-18
>
>Internet Protocol version 6 (IPv6) introduces a scoped unicast
>addressing architecture, including the concept of site-local
>addressing.  Although site-local addresses were originally
>allocated for use in networks that were not yet connected to the
>Internet, there has been work underway for several years to expand
>the use of site-local addresses to globally connected IPv6 networks
>and nodes.
>The use of site-local addresses on globally connected networks and
>nodes raises complex technical issues for many parts of the TCP/IP
>protocol suite.  Many of these issues are caused by the fact that
>IPv6 sites are private address spaces, and site-local addresses are
>unreachable or ambiguous outside of site boundaries.  Site-local
>addresses also add significant complexity at the IP layer and at
>other layers of the protocol stack.  In addition, many of the
>benefits of site-local addressing can be achieved using mechanisms
>that are significantly less complex and that cause fewer problems
>than IPv6 site-local addressing.
>This document makes a recommendation to limit the use of site-local
>addresses to isolated, single-site networks, and offers suggestions
>for less complicated mechanisms to achieve many of the benefits
>currently attributed to IPv6 site-local addressing.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact-00.txt

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Hiroki Ishibashi <[email-masked]>
Date: Sun, 22 Dec 2002 04:52:02 +0900

Margaret,

Please let me verify two things on draft-wasserman-ipv6-sl-impact-00.txt.

1. Does 「The Impact of Site-Local Addressing in IPv6」try to 
   prohibit the use of SBR completely?

2. By the statement, 
	"IPv6 site-local addresses be limited to use on isolated, 
	 single-site networks.",

   are you prohibiting the network below?

         Global IPv6 Internet ------- SBR ------ Node with
                                                 Global IP and
                                                 Site-Local IP

By the way, our SBR is neither research nor test implementation.

--
Hiroki Ishibashi
[email-masked]

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 21 Dec 2002 16:41:48 -0500

Hi Hiroki,

>1. Does $B!V(BThe Impact of Site-Local Addressing in IPv6$B!W(Btry to

If the WG chooses to follow the recommendations in this document,
then SBRs will not longer be necessary.

>          Global IPv6 Internet ------- SBR ------ Node with

Exactly.  This would not be an isolated, single-site network,
as it is connected to the global Internet.

>By the way, our SBR is neither research nor test implementation.

Very interesting.  Is this a commercial product, or expected to
become one?  What routing protocols does it include?  Did you
experience the problems described in my document?  If so, how
did you resolve them?

Thanks,
Margaret

---

From: Hiroki Ishibashi <[email-masked]>
Date: Tue, 24 Dec 2002 11:24:43 +0900

Hi Margaret,

>>1. Does [The Impact of Site-Local Addressing in IPv6] try to

Yes, our SBR routers have been shipped since September, 2000 as
a commercial IPv4/IPv6 dual router.   It supports RIPng, OSPFv3, and
BGP4+.  I have explained our SBR support and routing protocols in this
mailing list once before when the site-local issues were brought up.

We are not supporting BGP4+ w/ SBR, but RIPng and OSPFv3.
RIPng is easy to support as Brian Haberman explained at Atlanta.
For OSPFv3, as you described in I-D, we are allocating separate OSPF
process for each area.  The current OSPFv3 does not consider SBR at all.
This is the reason for separating OSPF processes.

I have not played with SBR with DNS, but DNS related issues seem to be
very tricky.

Thank you,

==== HIROKI ISHIBASHI ==================================================
 3rd Network Systems Development Department, Business Networks Division
 E-mail: [email-masked]
 Phone:  +81-4-7185-7344     Fax:  +81-4-7185-7947
================================================== NEC Corporation =====
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 23 Dec 2002 21:33:36 -0500

Hi Hiroki,

>mailing list once before when the site-local issues were brought up.

I do remember your previous mail.  I didn't realize, though, that
you were talking about a commercial product -- I thought that you
had a research implementation.  I apologize for my mistake.

>This is the reason for separating OSPF processes.

Do these processes share a single global routing table, based on
the link-state advertisement from all peers?  Or perhaps you run one
"global" process and one "site-local" process per site?

I am interested to understand whether you maintain a single peering
relationship with each peer, exchanging both site-local and global
information in the same LSAs, or whether you have separate peering
relationships (and separate LSAs) for global and site-local
information.

I believe that it would work either way, but that we may need to
specify which way it should be done, as I am not sure that the
two choices are compatible.

>I have not played with SBR with DNS, but DNS related issues seem to be

Indeed.  Of course, most commercial routers are not frequently
used as client nodes, so the DNS issues are more of a concern for
workstation-based routers and/or site border hosts.

Margaret

---

From: Hiroki Ishibashi <[email-masked]>
Date: Tue, 24 Dec 2002 13:53:19 +0900

Hi Margaret,

>"global" process and one "site-local" process per site?

Currently, processes for sites are completely separated.
Let's say, a router has 4 interfaces, if1, if2, if3, and if4.
Sites are configured as:
	Site1 has if1 and if4.
	Site2 has if2 and if3.
In our current implementation, two OSPF processes are created as:
	OSPF process 1 runs for Site1.
	OSPF process 2 runs for Site2.
	
On each process, all routing information, including global and 
site-local are handled.  Because of this, a user need to "redistribute"
global prefixes (not site-local prefixes) each other.
This is the demerit of separating OSPF process per site.

As you described in the previous mail, we could run one "global" process
and one "site-local" process per site.  In this case, a interface need to
belong to two OSPF processes, one for global and another for site.
In this case, "redistribution" of global prefixes among sites will not 
be required.

In both cases, multiple OSPF processes are required since global and
site-local information could appear in single LSA according to 
the current OSPFv3 RFC.

                        if1
                         |              /Site Boundary 
                         |             /
                         |            /
               +---------+-----------+
               |                    /|
               |   Site1           / |
               |                  /  |
 if4-----------+   ---------------   +---------- if2
               |  /                  |
               | /         Site2     |
               |/                    |
               +----------+----------+
              /           |
             /            |
            /             |
           /              |
                          if3

Thank you,

Hiroki Ishibashi
[email-masked]

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 24 Dec 2002 06:30:16 -0500

>This is the demerit of separating OSPF process per site.

Thanks, Hiroki.  I think I understand...

Do you have some type of internal filtering mechanism to decide
which routes to "redistribute" from one OSPF process to the others?
Or are the OSPF processes using OSPF to speak to each other?

Externally, from an OSPF perspective, does your SBR look like a
single router?  Or like multiple (two in your example) routers
with logical links in between them?

Thanks,
Margaret

---

From: Hiroki Ishibashi <[email-masked]>
Date: Wed, 25 Dec 2002 10:50:36 +0900

Hi Margaret,

>which routes to "redistribute" from one OSPF process to the others?

No, one has to do it manually as you do for any other routing protocols.
It is much similar to the route redistribution from OSPF to BGP for
example.

>with logical links in between them?

Yes and No...  It is a hard question. 

In the case of:

	On each process, all routing information, including global and 
	site-local are handled.  Because of this, a user need to 
	"redistribute"global prefixes (not site-local prefixes) 
	each other.This is the demerit of separating OSPF process 
	per site.

global prefixes are redistributed among OSPF processes, so for a OSPF
process, routing information redistributed from other OSPF processes
are treated as AS-external (type 5 LSA) routes.  This is the difference 
compared with the non-SBR OSPF case.

In the case of:

	one "global" process and one "site-local" process per site.  
	In this case, a interface need to belong to two OSPF processes, 
	one for global and another for site.

from the global prefixes' point of view, single OSPF process covers all
sites, so the issue in the 1st case will not occur.  This might be a
little harder for programmers.

In any case, if one wants to handle global and site-local prefixes with
single OSPF process, someone needs to write an I-D to specify how to 
handle LSAs.

Thank you,
Hiroki Ishibashi
[email-masked]

---

From: Hiroki Ishibashi <[email-masked]>
Date: Mon, 30 Dec 2002 04:38:42 +0900

Hi Margaret,

>as it is connected to the global Internet.

In the Atlanta meeting, I voted for the Moderate usage.
The choices were as below:

    - Limited usage 
       only used in disconnected sites 
       no multi-site nodes 
    - Moderate usage 
       simple site-border router 
       no multi-site host or router requirements 
       two-faces/split DNS 
    - Full usage 
       require all nodes to be multi-site 
       routing protocols aware of site boundaries 
       multi-site DNS 

and the poll result was:

     No consensus: ~30 Remove, ~51 Limited, ~57 Moderate, ~17 Full 

I know that you are writing for the Limited usage, but your document
does not leave the possibility of the Moderate usage at all.

IMO, "8.2.1   Benefits for Newly-Connected Sites" in your document
is most beneficial point of site-local addresses for enterprise networks.
In many cases, enterprise networks are not required to have connectivity 
to the IPv6 Internet from the beginning.  It is much like a deployment 
(transition) scenario, but a company can start using IPv6 as its intranet 
now.  Allowing site-local addresses co-exiting with global addresses 
makes a transition from IPv6 Intranet to IPv6 Global Internet easier.  
Manual renumbering of site-local addresses to global addresses does 
not occur at one shot.  Even if IPv6 WG comes up with 
"provider-independent global addresses", we may face the similar 
issues as site-local addresses.  (Sorry if it's not.)
I have NOT understood the concept of "provider-independent global addresses"
completely.

For the reason above, Site-local is beneficial for Newly-Connected Sites
if the simple connected site case is allowed.

          Global IPv6 Internet ------- Simple SBR ------ Node with
                                       or                Global IP and
                                       Filer             Site-Local IP 
                                                         addresses

This kind of IPv6 deployment is far easier for the enterprise networks.
I have been thinking how to deploy IPv6 in the the enterprise networks 
for more than a year.

Very nice work on documenting the site-local issues, anyway.

Thank you,

HIROKI ISHIBASHI
[email-masked]

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 29 Dec 2002 15:26:42 -0500

Hi Hiroki,

>does not leave the possibility of the Moderate usage at all.

Right.  The recommendation in my document is for the limited usage.
Bob Hinden has written a draft that documents the moderate usage.
The WG will have to decide what we want to do -- there didn't seem to
be any clear consensus one way or the other in Atlanta.

>I have been thinking how to deploy IPv6 in the the enterprise networks

Yes.  I agree that we need some way for an enterprise to number its
networks for IPv6 and later connect to the IPv6 Internet.  With
our current policies of only routing provider-allocated addresses,
a site will need to use some sort of local addressing (current
site-local addressing, or some other type of non-globally-routable
addressing) and add globally-routable addresses when they connect to
the Internet.

I'd actually rather see us come up with a way that a site can get
its own globally-routable IPv6 address allocation, and have any
ISP route that allocation.  However, this could cause unacceptable
growth of the IPv6 routing tables.

I am working on another document that explains more about why we
need globally-routable, provider-independent addresses (addresses
that an enterprise can "own", like the original IPv4 addresses) in
order to avoid the deployment of IPv6-to-IPv6 NAT. Hopefully I will
post that in the next couple of weeks, and it may make it clearer
why I believe that we need globally-routable, provider-independent
addresses in IPv6.

>Very nice work on documenting the site-local issues, anyway.

Thank you.  That's actually the part I have spent the most time on,
as I believe that it is valuable for us to document the issues.  I'd
love to get some feedback from people regarding any mistakes I've made
and/or any issues that I have omitted.

If the WG wants to publish a document on the issues associated with site-
local addressing (which had been suggested on the list), it could probably
be based on the issues sections in my document, without necessarily
including my recommendations.

Thanks for the feedback.

Margaret

---

From: Keith Moore <[email-masked]>
Date: Sun, 29 Dec 2002 15:59:57 -0500

>        routing protocols aware of site boundaries

as I recall, Moderate was never well-defined and the definition (such 
as it was) kept changing.  Also, this way of splitting things doesn't 
define how applications are supposed to deal with Moderate or Full usage, 
and that's a significant variable.

bottom line: the Atlanta poll was essentially meaningless except
to indicate that there's a significant fraction of the group
that wants to discourage SLs to some extent.

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 29 Dec 2002 16:13:34 -0500

>that wants to discourage SLs to some extent.

Based on the minutes, we agreed at the time that the "poll" did
not demonstrate rough consensus of those present to pursue any
particular proposal.

We did ask a separate question, and did see rough consensus in
the room that we wanted to limit site-locals -- to the limited
proposal, the moderate proposal, or something in between.
We also agreed that we needed to document the two proposals,
so that we could discuss them in more detail on the list.

Margaret

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 30 Dec 2002 10:49:34 -0800

Keith Moore wrote:
> ...
> bottom line: the Atlanta poll was essentially meaningless 
> except to indicate that there's a significant fraction of the 
> group that wants to discourage SLs to some extent.
>

I agree. The question that wasn't asked is why they want the
restriction. Of the group that indicated a desire to restrict use of SL,
how many of those were based on the simple fear of change, the unknown,
or that SL automatically leads to nat? 

To be fair, I suspect that the number of participants that have actually
worked through the applications and infrastructure that work or not is
about the same for either side, and collectively <10% of those
expressing an opinion in Atlanta. 

SL was not intended to be a general purpose addressing mechanism, and
trying to use it as such will have failure modes. We know that large
network managers will insist on being independent of their provider(s),
and we know that routing that independence is a hard problem. That is
the reason that multi6 was tasked with focusing on that specific issue,
without distraction. Unfortunately, that group has gone into hibernation
for extended periods of time, and with the latest emergence seems more
interested in architectural changes that affect all applications, rather
than engineering a manageable multi-homing approach.

Personally I want to see us make progress on this front, and I don't
care which WG gets it done. The IESG probably has a different opinion,
so it may be challenging to get documents out of draft state.
Fortunately we can do the work and worry about getting it to RFC later.

Tony

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Dec 2002 14:01:27 -0500

> or that SL automatically leads to nat?

for that matter, similar questions could be asked of those who prefer 
full/unrestricted use of SL - since proponents of that view have certainly 
argued against restricting SL purely on the basis that this is a "change", 
and others have argued that restricting SL automatically leads to NAT.

Keith