Subject: Fwd: Re: IPv6 Scoped Addresses and Routing Protocols

From: Margaret Wasserman <[email-masked]>
Date: Wed, 05 Jun 2002 13:58:49 -0400

>X-Sender: [email-masked]
>Date: Fri, 24 May 2002 21:29:52 -0400
>To: Margaret Wasserman <[email-masked]>, [email-masked]
>From: Jeff Parker <[email-masked]>
>Subject: Re: IPv6 Scoped Addresses and Routing Protocols
>
>At 12:17 PM -0400 5/24/02, Margaret Wasserman wrote:
>>I raised some questions with Bill Fenner in Minneapolis regarding IPv6 scoped
>>addressing and our current IPv6 routing protocol specifications
>>...
>>(4) IS-IS-IPv6:
>>
>>IS-IS-IPv6 makes no mention of site-local or scoped addressing at all. Is this appropriate?  How will IS-IS
>>SBRs know not to propagate site-local routing information between two attached sites?  I don't yet
>>know enough about IS-IS to understand how site-local routing information would best be handled
>>in IS-IS.  Any thoughts?
>
>Margaret -
>         I don't know anymore about site-local than what I've read above, but perhaps I can help with how you might use ISIS.
>         ISIS is used today is as an interior routing protocol.  The boarder routers run ISIS on the 'inside' ('in site', in your terminology?) and use BGP to peer with the rest of the world.   In this scheme, BGP could filter out the site addresses when communicating with the outside.
>         Neither IS-IS nor OSPF scales past a certain size, somewhere in the 100 to 1000 router range.  But both have the notion of an area, and it should be possible to connect multiple sites (areas) together using the ISIS Level 2 notion, or OSPFs Area 0.  There would have to be provision to filter site address announcements from leaking into Level 2 (Area 0) if you tied multiple sites together with the IGP.
>
>- jeff parker

>From: Francis Dupont <[email-masked]>
>To: Margaret Wasserman <[email-masked]>
>cc: [email-masked]
>Subject: Re: IPv6 Scoped Addresses and Routing Protocols 
>Date: Sat, 25 May 2002 18:48:50 +0200
>Sender: [email-masked]
>X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
>
>  In your previous mail you wrote:
>
>    Sites boundaries run through routers, so a single router (called a
>    site border router (SBR)) can have interfaces in more than one site.
>
>=> a SBR is a nightmare... It needs a scoped routing table in the kernel
>and separate IGPs for each site. I don't want to imagine how we can
>support site reconfiguration on a running SBR.
>
>    SBRs will need to enforce site boundaries
>
>=> this part is easy: a very small number of lines of code in the forwarding
>routine.
>
>    not mixing site-local routing information
>
>=> this is called a scoped routing table (zoned should be a better term
>but unfortunately it is too late to fix RFC 2553 or even 2553bis...)
>
>    and not forwarding packets outside of a given site.
>
>=> this is "enforcing site boundaries", isn't this?
>
>    To do this, it is expected that SBRs will need to maintain multiple
>    "conceptual routing tables", including one site-local routing table
>    for each attached site, and one global routing table.
>    
>=> in fact usually a zone ID is added to addresses for the same result.
>
>    None of our IPv6 routing protocol documents deal with site-local
>    boundaries or SBR behaviour explicitly.
>    
>=> one can expect a site is a routing domain and an internal gateway protocol
>should be run in the site. As routing protocols carry raw addresses (i.e.,
>in a case of a scoped address, the address without its zone indication)
>this is the only reasonable way.
>
>    Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing:
>    http://www.ietf.org/rfc/rfc2545.txt
>    
>=> two remarks:
>  - usually BGP is used as an inter-domain routing protocol so is supposed
>    to manage routes for global prefixes.
>  - the issue is partially addressed in the section 2 (partially == not
>    fully solved).
>In fact, the multi-protocol feature of BGP 4+ provides some ways to carry
>extra information in a NLRI. For instance, we can reuse a VPN-like
>(cf RFC 2547) way to manage site-local addresses with site identifiers.
>
>    RIPng for IPv6
>    http://www.ietf.org/rfc/rfc2080.txt
>    
>=> its poor scalability makes RIPng a bad candidate for multi-sited stuff.
>
>    So here are my actual questions:
>    
>    (2) BGP-IPv6:
>    
>    Would it ever be reasonable for BGP to propagate site-local routing
>    information?
>
>=> I've already answered this should be possible in the hard (== multi-sited)
>case. Personally I believe site-local addresses should be reserved to the
>not-connected organizations: the "non-link-local" argument applies.
>(PS: here not-connected is at the network layer)
>
>    Why, under what circumstances?
>
>=> very large not-connected organizations?
>
>    Would it be reasonable to assume that an Inter-Domain Routing protocol
>    shouldn't propagate site-local information at all?
>    
>=> I'd like to say site-local information should not cross site boundaries.
>
>    If BGP should be capable of propagating site-local information,
>    will it be possible, using existing BGP standards for a BGP SBR router
>    with four interfaces (A, B, C & D), in two sites (A & B in S1, and C &
>    D in S2) to maintain two separate sets of information for prefix
>    FEC0::/10, one that applies to S1 (interfaces A & B) and one that
>    applies to S2 (interfaces C & D), and to propagate that information
>    accordingly?
>
>=> I am not an expert of RFC 2547 but site-local addressing fulfills
>the 1.3 requirement about overlapping address spaces so a similar
>tagging of site-local addresses (RFC 2547 adds a "Route Distinguisher"
>which identifies a VPN, we can use the same concept for identifications
>of sites) should work.
>
>    Is this really just an issue of configuring the router properly, as
>    BGP-IPv6 implies?
>
>=> not for the multi-sited case because a router is not supposed to run
>more than one BGP-IPv6 process. But in other cases I agree with the
>suggession of BGP-IPv6 (i.e., I still believe BGP-IPv6 doesn't need
>to be updated).
>
>    (3) OSPF-IPV6:
>    
>=> OSPF-IPv6 has the new (over OSPFv2) property that one is allowed to
>run more than one OSPF-IPv6 process per router. So with a dangerous but
>possible configuration the multi-sited case can be handled.
>
>    Unlike the previous specification (BGP-IPv6), this assumption is
>    not stated up-front.  Instead, everywhere in the draft where either
>    site-local or global addresses are mentioned they are both mentioned
>    (i.e.  "site-local or global IPv6 addresses").
>    
>=> results are 5 and 80 pages (totally unfair comparison :-)!
>
>    Or to assume that an OSPF AS will always be completely contained
>    within one site -- which is what the current draft seems to assume?
>    
>=> I agree but this is not a limitation because one may run multiple
>OSPF-IPv6 processes per router, i.e. put a router in multiple ASs.
>
>    (4) IS-IS-IPv6:
>    
>    Any thoughts?
>
>=> I believe IS-IS-IPv6 assumes an AS is completely contained in one site
>but there is no multiple process capability (my argument is the CLNS
>addressing is per node, not per interface. A well-known consequence is
>IS-IS can not run as an external gateway protocol). But this applies
>to the original IS-IS lightly modified to carry IPv4 addresses (as decribed
>in the reference).
>    
>    (5) RIP-IPv6:
>    
>    The RIP-IPv6 document explicitly states that there is a single IPv6
>    routing table.
>
>=> so RIP-IPv6 has explicitly no provision for the multi-sited case.
>    
>    (6) Will the MIBs for any of these routing tables be capable of
>    representing multiple independent, possibly overlapping sets of
>    site-local routing information?
>
>=> in the case of BGP 4 (the only one I know because MIBs are the reason
>the RFC 2553 is not yet a Draft Standard :-) all references in
>draft-ietf-idr-bgp4-mibv2-02.txt point to RFC 3291 which defines ipv6z
>addresses: "A non-global IPv6 address including a zone index as
>defined by the InetAddressIPv6z textual convention"!
>
>    (7) Do you think that there would be some utility to defining the
>    actual routing architecture (as opposed to just the addressing
>    architecture) for IPv6?
>
>=> no because we shan't easily get a consensus (there are two strong
>opposite opinions about the use of sites).
>
>    (8) Should we mention link-local addresses anywhere in these specifications?
>
>=> not in specifications when they are enough clear but in applicability
>documents.
>
>    We certainly would not want to propagate routing information for
>    link-local addresses.
>    
>=> perhaps this is the opportunity to solve a very old issue raised by
>Jean-Luc Richier many years ago: a topology discovery tool using SNMP
>to dump routing tables can not go beyond directly connected routers
>because it gets useless link-local addresses of next routers...
>
>Thanks
>
>[email-masked] 

--------------------------------------------------------------------
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: Wed, 05 Jun 2002 14:00:04 -0400

---

From: "Smith, Mark - Sydney" <[email-masked]>
Date: Thu, 6 Jun 2002 10:52:01 +0800

I've only briefly read through the scoped architecture draft, running an IGP
per zone might be more correct, although I can only think of one instance
where there would be multiple zones and multiple IGPs running, and that is
for site-level zones, so the SBR / ZBR(?) terminology is really the same
thing.

Mark.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, 6 June 2002 8:22
> To: Margaret Wasserman
> Cc: [email-masked]
> Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols 
> 
> 
> >Unfortunately, I can't find any indication that these 
> concepts have been reflected 
> >in the current IPv6 routing protocols.  None of our IPv6 
> routing protocol documents
> >deal with site-local boundaries or SBR behaviour explicitly.
> >
> >There are currently four standards for how IPv6 routes will 
> be handled in BGP, OSPF, 
> >IS-IS and RIP. I will refer to these documents as BGP-IPv6, 
> OSPF-IPv6 and IS-IS-IPv6,
> >and RIP-IPv6 respectively:
> 
> 	in my opinion, site border routers need to have ability to run
> 	separate entity of RIP/OSPFv3/IS-IS for each site 
> (don't mix them up).
> 	there's no need for protocol modification, since there 
> will be no
> 	interaction between routes in site A and site B.
> 
> 	NEC IX router is the only implementation supporting 
> this, as far as
> 	i know (i'm a bit embarrassed, KAME doesn't handle this - yet).
> 
> itojun

---

From: "Michel Py" <[email-masked]>
Date: Sun, 9 Jun 2002 12:46:31 -0700

> Ralph Droms wrote:
> Regarding "Routers must not forward any packets with site-local source
> or destination addresses outside of the site." [RFC 2373] (note lower
> case for "must not"): the problem is not so much a vendor problem as
> a deployment problem.  A router can't know when it's forwarding a
> packet outside of a site unless it's been configured with information
> about site borders. So network architects and admins have to define
> what makes up sites and configure the routers at the borders to know
> about those site borders.

Exactly.

> I don't see much difference between RFC 1918 addresses and site-local
> addresses in the areas of network design and deployment...

The difference is that an RFC 1918 host is likely to have access to the
outside world through NAT, when a site-local only v6 host is _not_. And
we all agree that the "security" provided by RFC 1918 addresses is a
joke, mostly because of the presence of NAT.

In the v4 world, it is typical to have only one v4 address per host
interface, and therefore where there is RFC 1918 addresses you can bet
there is NAT nearby.

The v6 situation is different: One does not need NAT to access the
outside and use site-local at the same time. Therefore, one of the
reasons people would use site-local addresses is for security reasons,
and not a by-product of not having enough v4 addresses.

The question Steve Bellovin was asking (if I interpret it correctly) is
more or less "does anybody need site-local addresses anyway?". I do.

Michel.

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 09 Jun 2002 19:09:02 -0400

Hi Michel,

>more or less "does anybody need site-local addresses anyway?". I do.

What do you need them for?

Margaret

---

From: "Dave Thaler" <[email-masked]>
Date: Mon, 10 Jun 2002 13:27:01 -0700

> From: Bill Fenner [mailto:[email-masked]]
[...]
> It's fairly clear how to allow A and F to not advertise site-local
> addresses across the boundary (at least, as long as it coincides with
a
> routing protocol boundary, e.g. OSPF area).  However, if H1 knows that
> H2 is witchin the same site, H1 is allowed to use its site-local
source
> address to send to H2's global address.  However, along the
H1-A-D-F-H2
> path, A would have to drop the packet because it has a site-local
address
> and is trying to cross a site boundary.

Yes, scopes have to be convex.  This is not new in IPv6.
See section 7 of the IPv4 scoped multicast RFC (2365).

-Dave

---

From: Bill Fenner <[email-masked]>
Date: Mon, 10 Jun 2002 13:37:05 -0700

>See section 7 of the IPv4 scoped multicast RFC (2365).

The worry is that people might look at routing protocols mechanisms
that keep the site convex wrt site-local addresses and consider
that sufficient.

draft-ietf-ipngwg-scoping-arch-03.txt only says:

           o Each zone is required to be "convex" from a routing
             perspective, i.e., packets sent from one interterface to
             any other interface in the same zone are never routed
             outside the zone.

which does not seem to preclude my example topology, since the routing
protocol causes the site-local scope zone to be convex.

  Bill

---

From: "Dave Thaler" <[email-masked]>
Date: Mon, 10 Jun 2002 13:56:35 -0700

[...]
> protocol causes the site-local scope zone to be convex.

I believe it does preclude your example topology, since you have
packets sent from one interface (H1's) to another interface (H2's)
that are routed outside the zone.  The fact that the destination address
is global is orthogonal.

-Dave

---

From: Bill Fenner <[email-masked]>
Date: Mon, 10 Jun 2002 14:25:43 -0700

I think this restriction precludes lots of real network topologies.
I also think that the wording in the spec needs to be a little more
clear that it means globally convex and not just convex with respect
to the zone-scoped addresses.

  Bill

---

From: [email-masked]
Date: Tue, 11 Jun 2002 09:46:34 -0400

On Tuesday, 06/11/2002 at 01:47ZE10, [email-masked] wrote:
>     Putting limited-scope addrs in DNS is a bad idea *unless*
>     you have a way to uniquely identify the scope.
>
>     Neither AAAA or A6 provide support for this.  I made a proposal
>     that would have added this to A6 *before* there was any A6
>     deployment.  It got totally ignored by the IPv6 community (with
>     the exception of Matt).
>
>     Now might be a good time to raise the idea again except I won't
>     tie it to A6.
>
>     <ownername> SA <IPV6 address> <scopename>
>
>     SA      scoped address
>     scopename is a domainname choosen to be globally unique.
>             global addresses have a scopename of ".".
>
>     the conversion from scopename to scopeid / zoneid is a
>     *local* resolution problem for the machine.

So, to make SL work, we need changes to the DNS name server, changes
to the resolver, routers to advertise the scope zones, hosts to
learn the scope zones from routers and include them on DDNS
registrations and use them in making routing decisions, updates to
routing protocols, IANA needs to manage a new zone scope naming
space, and who knows what else.

Wouldn't it make sense to hold off on SL until we at least have
some proposals on the table which describe the changes necessary to
make SL work, at which time we could have a discussion on the
technical merits of the proposal(s)?  Until that time, though, the
SL unicast address space should either be reserved or moved to
experimental.

Roy

---

From: "Dave Thaler" <[email-masked]>
Date: Tue, 11 Jun 2002 10:53:51 -0700

> From: Markku Savela [mailto:[email-masked]]
> Sent: Tuesday, June 11, 2002 10:17 AM
> To: [email-masked]
> Well, I've not yet fully gotten into issue of getting site local
> addresses from the name server, but...
>
> ... I assume when a resolver gets an address as a reply from the DNS,
> it will supply the scope id from the interface which the DNS reply
> came in. And, this applies to all scope levels (consider, multicast
> groups could be in DNS too, with any of the 15 or so scope levels).

Correct.

> Now, for this to truly work, the DNS server does need some extra code
> to deal with non-global scopes. The database must include the scope in
> some form (for example interface name), and it must not return replies
> of non-local addresses to other than indicated interface.

Or just implement Erik Nordmark's draft on the host and the DNS server
doesn't need to do anything.  This is the approach we prefer (not to
say we have any objection to modifying the DNS server too, just that
it can work without it).
 
> However, this seems to be a local implementation issue, which does not
> change the protocol on the wire.
> 
> I think similar considerations apply to routing protocols: the zone
> ids are always available from the interface which the packet is
> using. Of course, some system admin must configure them to the
> interface first.

Correct.

-Dave

---

From: Derek Fawcus <[email-masked]>
Date: Tue, 11 Jun 2002 21:36:03 +0100

My view on site local addresses is a bit split.

From a personal point of view I like them.  I can use them in my home
network,  together with global addresses (6to4 at the moment),  and
even store them in my local DNS server.  None of this causes me
any problems,  it all works and means if/when an ISP in the UK is
able to supply me with real IPv6 global addresses I'll not have to
alter much.

As things stand if someone was to query my DNS server from the
outside world (assuming the domain I'm using delegated to me),
they'd not see any SL addresses - split DNS.

This is the simple scenario of SL enabled globally at home,  and
having a couple of (site) border routers,  both of which have some
global interfaces and some site interfaces.  Both routers only know
about the one site - the same site.

However as an router implementor - they're a right royal pain.

One major issue being the possibility of having more than one site
cutting through the router.  For a single CPU router this is not
too bad,  for a multi CPU router it is awkward.

Now even if we were to simplify things so that a node (router) could
not attach to more than one site at a time (i.e. the case of site
links,  and non-site (global) links),  things'd not stay simple
for long.

I say this 'cause I'd anticipate that someone would want to supply
outsourced managed 'Site' networks in the same fashion as ISPs
offer managed VPNs at the moment.  This would effectively collapse
things back into the situation we have at the moment with multi-site
routers.

  --

Overrall I guess I'd say keep them,  then hope they never get deployed
at anything other than the sort of use I personally have for them.

This basically means that they'd not be of much use for anything other
than small scale use, and (as someone else pointed out) are of no use
to large organisations with geographically diverse facilities.

What does worry me though is if customers (ISPs) want to have the same
sort of VPN facility I've mentioned above - this seems to naturally
coincide with the v6 view of SL addresses,  and raises very similar
issues to be solved.

The real answer to the underlying problem here is a lot harder to
solve.  It all seems to mainly be about security,  and it would
seem that IPsec should be used to address it.  However the issue
of having keys distributed,  and prooving identity still needs
to be rolled out.

DF

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 11 Jun 2002 19:46:46 -0400

In message <[email-masked]>, Derek Fawcus writes:
>On Tue, Jun 11, 2002 at 12:07:23PM -0700, Alain Durand wrote:
>> 
>> The ICMP name lookup tells you who a node pretends to be,
>> not what its globally unique assigned name has been cryptographically 
>> verified
>> You may or may not trust this information.
>> For local debuging purpose, it is valuable information, but it would 
>> certainly raises major concerns if it were to be applied on the Internet.
>
>But surely you simply use the name retrned to do a forward lookup and
>verify that the original address is one of those returned?
>
Precisely.  The cryptographic signature is not magic; it's the 
assertion of validity by the owner of the address space.  How do you 
know the owner is telling the truth?

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com ("Firewalls" book)

---

From: "Michel Py" <[email-masked]>
Date: Wed, 12 Jun 2002 14:39:21 -0700

> kre wrote:
> There is way too much of the latter in all areas of the IETF these
> days. I don't know the answer to this today, so I will forbid it
> forever.

Yep. I will write a requirements draft that is impossible to meet so it
will be forbidden for ever.

> SL addresses are just fine.   More work is needed on them for sure,
> to make them even more useful, and suggesting to people that until
> the implementations better support them, they should consider very
> carefully before enabling the things, is all just fine. But
> there's no reason at all to be even considering deleting them.

I agree.

Michel.

---

From: "Dave Thaler" <[email-masked]>
Date: Mon, 10 Jun 2002 13:27:01 -0700

[...]
a
source
H1-A-D-F-H2
address

-Dave

---

From: Bill Fenner <[email-masked]>
Date: Mon, 10 Jun 2002 13:37:05 -0700

Bill

---

From: "Michel Py" <[email-masked]>
Date: Thu, 13 Jun 2002 08:53:15 -0700

> Jim Bound wrote:
> and this is my biggest fear for the Internet with IPv6.  These
> site-locals could undo all we did with IPv6 to restore end-to-end
> architecture for the Internet.
> Trying to limit them with words or BCPs whatever will NOT prevent
> the potential tragedy to our beloved Internet

I share your concern, I just don't think that there are good reasons to
develop IPv6 NAT. Besides, there are plenty of other things that break
end-to-end and will continue to break it: Load balancers, cache engines,
etc.

A word about "warm an fuzzy":
"warm and fuzzy" is a requirement. There will be IPv6 firewalls, I
actually think there will not be any serious IPv6 setup without a
firewall.

What is a firewall? It's a big, bulky, very expensive rack-mounted
device with the word "firewall" screened in big letters on the front.
What does it do? It makes senior management feel secure.

A firewall does not protect a network more than a private IP does. It
can be bypassed as I explained before. I regret to report that the very
existence of firewalls and load balancers is not something you and I
will change. I would apply the same reasoning to site-local addresses.

Michel.

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Jun 2002 08:31:33 -0400

one of the rare times I get randy's wisdom and agree :---)

/jim

> From: Randy Bush [mailto:[email-masked]]
> Sent: Thursday, June 06, 2002 2:25 PM
> To: Steven M. Bellovin
> > My strong preference would be to drop site-local addresses 
> completely.  
> > I think they're an administrative and technical nightmare.
> 
> trying to solve a routing problem by an ill-understood addressing
> hack.
> 
> randy
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Jun 2002 08:41:03 -0400

link-locals should live.

site-local in this case can be multicast limited by scope that would be similar to site-local.  that is neeeded for multicast and the scope is better than the IPv6 TTL use.
But we don't need unicast site-locals is what I support.

/jim

> From: Ralph Droms [mailto:[email-masked]]
> Sent: Friday, June 07, 2002 1:15 PM
> To: [email-masked]
> Cc: Keith Moore; R.P. Aditya; [email-masked]
> DHCPv6 currently uses a site-scoped multicast address as the 
> default for
> forwarding messages from a relay agent to servers.  The relay 
> agent can be
> configured with a list of unicast addresses for servers 
> instead of using
> the site-scoped multicast address.
> 
> DHCPv6 also depends on link-local addresses for communication 
> between the
> client and the on-link relay agent.
> 
> - Ralph
> 
> On Sat, 8 Jun 2002 [email-masked] wrote:
> 
> > >> For link-local addresses, as long as the scope is
> > >> well-defined, what are your objections?
> > >for the most part, they're only a problem if you try to use
> > >them in applications (where zero-configuration appliances
> > >are an important subset of applications)
> > >part of the problem is that the scope of link-local addresses
> > >is *not* well-defined from an application's point of view,
> > >since applications in general don't know, and shouldn't have
> > >to know, about network topology.
> >
> > 	as long as the applications are properly implemented 
> with sockaddrs,
> > 	they are okay.  the problem reside in protocols that pass IPv6
> > 	addresses in payloads (since view of the scope is 
> different by nodes),
> > 	including:
> > 	- FTP (EPSV/EPRT does not help - for instance, how do you decide
> > 	  the scope zone for data connection?)
> > 	- DNS (AAAA/PTR does not represent scope correctly)
> > 	- and all NAT-unfriendly protocols
> >
> > 	I'm okay to see site-local IPv6 address to go away, however, I'm
> > 	worried because there are more than a couple of 
> protocols designed with
> > 	site-local IPv6 address in mind (DHCPv6, router 
> renumbering, ...).
> >
> > 	we need to keep link-local IPv6 address at least for ND.  use of
> > 	link-locals within zeroconf environment needs further study.
> >
> > itojun

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Jun 2002 08:41:46 -0400

ack to keith.  we had to hack this in to apis.  be nice if it left the api too.
/jim

> From: Keith Moore [mailto:[email-masked]]
> Sent: Friday, June 07, 2002 1:17 PM
> To: [email-masked]
> >         as long as the applications are properly 
> implemented with sockaddrs,
> >         they are okay.  
> 
> sockaddrs do not solve the problem of applications having to 
> figure out how
> to reach a peer application in the absence of any knowledge 
> about network
> topology.  the source-selection rule isn't sufficient either.
> 
> > the problem reside in protocols that pass IPv6
> it's entirely appropriate for applications to pass addresses 
> in payloads,
> and it's essential functionality for many kinds of applications
> (distributed apps in particluar).
> 
> for better or worse, the internet does not have a 
> location-independent namespace
> that is reliable and useful for doing referrals to peer 
> processes.  and nobody
> has demonstrated an effective way to retrofit one into the 
> current architecture.
> 
> we agree about that much.  but they think they're ready for 
> standards-track.
> 
> Keith

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Jun 2002 08:45:44 -0400

Bob,

As one who has worked with you a long time and always fight to not break existing implementations in this case I don't find your (and mine to some degree) abstracts for site-local compelling enough.  I think they are very bad and evil for the Internet too and more importantly private enterprise.

The code changes for this  are quite minimal too.  API tweek which can be done in follow releases, and the base IP stack has not evolved for scoping and now routing exists with this feature.

I think we should kill these now.

/jim

> From: Bob Hinden [mailto:[email-masked]]
> Sent: Friday, June 07, 2002 6:57 PM
> To: Steven M. Bellovin
> Steve,
> Thanks for raising this issue on the list.  I think it has 
> been lurking for 
> a while.
> 
> (with no hat on)
> 
> Here is my personal explanation about why site-local 
> addresses exist.  My 
> intent of the email is to not take a strong position on either side.
> 
> I think the important question is the one at the end of your email:
> 
> >Finally -- and perhaps least important -- I'm not sure what problem
> >they solve.  I can understand site-local multicast, since (most)
> >inter-site traffic traverses links that are not inherently
> >multicast-capable.  There is thus considerable extra 
> expense.  But why
> >do I need site-local unicast addresses?
> 
> It may be the most important question, not the least important :-)
> 
> One of the original reasons for site-local unicast addresses 
> was for sites 
> that were not connected to the Internet (and didn't have any global 
> addresses).  They would allow IPv6 be used inside the site 
> initially.  Later when the site become connected to the 
> Internet it would 
> be easy to renumber to a global prefix because the subnet part of the 
> addresses (/48 in current assignment practice) could be 
> reused without any 
> site subnet renumbering.  This usage of site-local unicast 
> may still have 
> some value and avoids some of the complexity of using a 
> mixture of global 
> and site-local addresses.
> 
> Later as many people came to belive that private addresses 
> (and NAT) in 
> IPv4 provide a security mechanism, Site-local addresses were 
> looked on as 
> filling that role in IPv6.  I understand that the belief that private 
> addresses provide security is faulty and has many nasty 
> consequences, but 
> many people do believe it.  I think this has evolved to where 
> there is a 
> view that using site-local unicast addresses for services 
> that need to be 
> restricted to the site is a good thing.  I think there is 
> some value here, 
> but am not sure if it's benefits justify it's costs.  I think 
> there are a 
> range of opinions here.
> 
> All of the issues you point out about site-local regarding 
> DNS and routers 
> are real.  However with the widespread use of IPv4 private 
> addresses in the 
> internet, that vendors have leaned how to deal with addressing domain 
> issues.  I don't think the IETF has done very much to 
> "standardize" this 
> usage (probably a good thing).  I think most vendors building these 
> products know how to deal with the issues and users have 
> learned how to 
> configure the products to solve their problem.  The vendors built it 
> because their customers wanted it.  It is all very ugly and 
> nasty.  It is 
> hard to set up and even harder to debug problems.  Perhaps 
> even as you say 
> "an administrative and technical nightmare".  But as far as I 
> can tell it 
> does exist.  If vendors are going to build products that want to use 
> site-local, then it might be best for the IETF to at least 
> document it's 
> usage to allow for interoperability.
> 
> (with my IPv6 co-chair hat on)
> 
> I think the w.g. has some choices to make regarding 
> site-local addresses.
> 
> 1) Remove site-local from the IPv6.
> 
> This would involve remove it from the IPv6 addressing 
> documents and find 
> all other documents that mention them and update these.  Some 
> of these may 
> require significant modification if use site-local as a basic 
> part of their 
> mechanisms.  There will also be an impact to shipping IPv6 
> implementations.  This would have to be sorted out.  A good 
> understanding 
> of what different vendors plan here would be useful.
> 
> 2) Keep site-local but limit it's scope of usage.
> 
> This would be something like writing an applicability 
> document that defines 
> it usage and for example restricts it use to sites not 
> connected to the 
> Internet.  Other usage would be for future study.  This would 
> be consistent 
> with most of the current specifications.  It would make 
> completing the 
> scoped address architecture document simpler.  There might be other 
> specifications to update if they were using site-local and 
> didn't have any 
> provision to move to global addresses.
> 
> 3) Keep site-local and allow full usage
> 
> This would mean fully specifying how to use site-local, 
> documenting the 
> router and DNS issues, completing the scoped addressing architecture 
> document, perhaps enhancing IPv6 routing protocols to have 
> more knowledge 
> of site-local addresses, etc.
> 
> The working group has been going down 3) for some time now.  
> I think your 
> email is a good start at seeing if should continue in this 
> direction or 
> change course.
> 
> Bob
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Jun 2002 08:49:27 -0400

Michel,

Your view of planet could be the IPv4 NAT view and with true e2e with IPsec, TLS, and many others those security interrupts and gateways that see my conversations on the net will go away.  So I don't like the way the planet is and we should change it.

/jim

> From: Michel Py [mailto:[email-masked]]
> Sent: Friday, June 07, 2002 10:32 PM
> To: [email-masked]
> Cc: Bob Hinden; Steven M. Bellovin; [email-masked]
> Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols 
> 
> 
> >> Michel Py wrote:
> >> On the other hand, considering that a typical IPv6 will 
> _not_ feature
> >> IPv6 NAT, an IPv6 host that has _only_ a site-local address would
> have
> >> an extra layer of protection against external attacks as 
> it would not
> be
> >> reachable at all from the outside.
> 
> > Bill Sommerfeld wrote:
> > I see this as a distinction without a difference -- if the site has
> > some systems running a global p2p network's software with external
> > connectivity, and that p2p network is cracked, the site will be
> > vulnerable to attacks relayed through the p2p network.
> > if one system within the site has external connectivity and is part
> > of the compromised p2p network, any system at the site will now be
> > open to attacks from the compromised system.
> 
> I don't know on which planet you are living, but on earth a 
> system that
> has no direct access to the outside is more secure than a system that
> does; this is called a fact, not a distinction. Security is the sum of
> different things, including passwords, firewalls _and_ 
> preventing direct
> access from the Internet.
> 
> 
> > If there is widespread deployment of systems with site-local only
> > addresses, this will in turn drive the creation of ipv6 NAT
> > specifically to give them external connectivity..
> 
> That looks like a solution without a problem. To give these hosts
> connectivity you just have both the site-local and the global address.
> Since NAT would not bring anything to the table why implement 
> it in the
> first place?
> 
> Michel.
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Jun 2002 08:54:44 -0400

Brian,

It would not be significant to rip the site stuff out of the code as I see it.

/jim

> From: Brian Haberman [mailto:[email-masked]]
> Sent: Sunday, June 09, 2002 10:33 AM
> To: Margaret Wasserman
> Hi Margaret,
>      I suppose that I should admit to being remiss in this area.  I
> have done a fair amount of work in this area and just haven't had the
> time to document routing protocol behavior changes to support site
> local prefixes (even though I recall telling you I was going 
> to do it).
> 
>      Anyway, I will start by saying that I have modified RIPng to
> correctly handle the advertisement of site-locals.  In order to make
> this efficient, I maintained the concept of a single instance of RIPng
> running in the router.  In order to understand the changes to the
> routing protocol, you also have to understand the changes to the
> RIB for site locals.  So, how did I make it work?
> 
>      1. The RIB now contains an additional field, the zone ID.  I
>         have done this in two different ways.  The first is to add
>         the zone ID as a separate field.  The second is to embed
>         the zone ID in the "unused" portion of the site local
>         prefix.
> 
>      2. RIPng was changed to build its route advertisement messages
>         on a per zone ID basis.  That is, it starts with adding all
>         global prefixes to the message.  It then adds site local
>         prefixes that are in the same zone ID as the interface that
>         the advertisement will be transmitted.  It determines this
>         by extracting the zone ID from the outgoing interface and
>         using this find all site locals in the RIB with a matching
>         zone ID.
> 
>      3. When RIPng receives a route advertisement from a peer, it
>         takes the zone ID from the receiving interface and using
>         that to add the site local prefixes to the RIB.
> 
> That, in a nutshell, allows a single instance of RIPng to control
> the advertising of site local unicast prefixes.  Though I haven't
> done the work, I would see OSPF as acting in a similar manner.
> 
> If someone wants me to describe the actual forwarding, just let me
> know.
> 
> Regards,
> Brian
> 
> Margaret Wasserman wrote:
> > 
> > I sent the attached message to the routing area discussion 
> list.  I thought that people on
> > the IPv6 list might be interested in this discussion, so I 
> will forward a message containing
> > the responses after this one.  I suppose I just should have 
> cc:ed the IPv6 group in the
> > first place...
> > 
> > Margaret
> > 
> > >Date: Fri, 24 May 2002 12:17:04 -0400
> > >To: [email-masked]
> > From: Margaret Wasserman <[email-masked]>
> > >Subject: IPv6 Scoped Addresses and Routing Protocols
> > >
> > >
> > >
> > >Hi All,
> > >
> > >addressing and our current IPv6 routing protocol 
> specifications, and Bill suggested
> > >that I should send my questions to this list for 
> discussion.  So, here they are.
> > >
> > >First, some background...
> > >
> > >As many of you probably know, IPv6 includes the concept of 
> scoped unicast
> > >addressing -- a unicast address can have link-local scope, 
> site-local scope
> > >or global scope.  The address scopes are defined in the 
> IPv6 Addressing
> > >Architecture:
> > >
> > 
> >http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-ar
> ch-v3-07.txt
> > >
> > >Additional information can be found in the IPv6 Scoped Address
> > >Architecture:
> > >
> > 
> >http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping
> -arch-03.txt
> > >
> > >I would suggest that all of you read the IPv6 Scoped 
> Address Architecture
> > >document, if you haven't already, as it contains 
> information regarding
> > >the expected configuration and forwarding behaviour of 
> IPv6 routers.
> > >It also defines the concept of an IPv6 site, which is 
> important to understanding
> > >the questions that I am about to raise.
> > >
> > >In IPv6, there is a concept of site-local addressing that 
> is quite different
> > >from the concept of "net 10" addresses in IPv4.  Sites are 
> administratively
> > >defined entities that must be "convex" (i.e. the best 
> route between two nodes
> > >in the site must, at all scopes, fall completely within 
> the site).  Sites boundaries
> > >run through routers, so a single router (called a site 
> border router (SBR)) can
> > >have interfaces in more than one site.  And, IPv6 
> site-local addresses can be
> > >used for site-constrained communication, even when a site 
> is globally
> > >connected and global addresses are available.
> > >
> > >Because all site-local addresses use the same well-known 
> site-local prefix, the
> > >only way to tell that a particular site-local address 
> belongs to a particular
> > >site is to know which site originated the address.  SBRs will need
> > >to enforce site boundaries, not mixing site-local routing 
> information, and not
> > >forwarding packets outside of a given site.  To do this, 
> it is expected that
> > >SBRs will need to maintain multiple "conceptual routing 
> tables", including one
> > >site-local routing table for each attached site, and one 
> global routing table.
> > >
> > >There are currently four standards for how IPv6 routes 
> will be handled in BGP, OSPF,
> > >IS-IS and RIP. I will refer to these documents as 
> BGP-IPv6, OSPF-IPv6 and IS-IS-IPv6,
> > >OSPF for IPv6
> > >http://www.ietf.org/rfc/rfc2740.txt
> > >
> > >Routing IPv6 with IS-IS:
> > >http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-02.txt
> > >
> > >RIPng for IPv6
> > >(1) Are the statements regarding the routing system in the 
> IPv6 Scoped Addressing Architecture
> > >draft valid?  Will they work in real life?  Please read 
> it, and comment to the IPv6 WG if you think that
> > >there are any issues with what it says.
> > >
> > >(2) BGP-IPv6:
> > >
> > >BGP-IPv6 states:  "As this document makes no assumption on 
> the characteristics of a particular
> > >routing realm where BGP-4 is used, it makes no distinction 
> between global and site-local addresses
> > >and refers to both as "global" or "non-link-local"."
> > >
> > >Would it ever be reasonable for BGP to propagate 
> site-local routing information?  Why, under
> > >what circumstances?  Would it be reasonable to assume that 
> an Inter-Domain Routing protocol
> > >If BGP should be capable of propagating site-local 
> information, will it be possible, using existing
> > >BGP standards for a BGP SBR router with four interfaces 
> (A, B, C & D), in two sites (A & B in S1,
> > >and C & D in S2) to maintain two separate sets of 
> information for prefix FEC0::/10, one that applies
> > >to S1 (interfaces A & B) and one that applies to S2 
> (interfaces C & D), and to propagate that information
> > >accordingly?  Is this really just an issue of configuring 
> the router properly, as BGP-IPv6 implies?
> > >
> > >(3) OSPF-IPV6:
> > >
> > >In this specification, no distinction is made between 
> site-local and global addresses.  Unlike the
> > >previous specification (BGP-IPv6), this assumption is not 
> stated up-front.  Instead, everywhere in
> > >the draft where either site-local or global addresses are 
> mentioned they are both mentioned (i.e.
> > >"site-local or global IPv6 addresses").
> > >
> > >Again this specification makes no provision for separate 
> sets of site local information.  There is
> > >also no mention of a boundary for site-local route 
> propagation, and no mention of multiple conceptual
> > >sets of site-local routing information.  Would it make 
> sense to tie the concept of an IPv6 site to
> > >one of the existing propagation boundaries in OSPF, such 
> as an OSPF area?  Or to assume that
> > >an OSPF AS will always be completely contained within one 
> site -- which is what the current draft
> > >seems to assume?
> > >
> > >(4) IS-IS-IPv6:
> > >
> > >IS-IS-IPv6 makes no mention of site-local or scoped 
> addressing at all. Is this appropriate?  How will IS-IS
> > >know enough about IS-IS to understand how site-local 
> routing information would best be handled
> > >in IS-IS.  Any thoughts?
> > >
> > >(5) RIP-IPv6:
> > >
> > >The RIP-IPv6 document explicitly states that there is a 
> single IPv6 routing table, and it makes no
> > >mention of sites.  I think it would be fine to constrain 
> RIP to operating within a single IPv6
> > >site, but that should be explicitly stated somewhere.
> > >
> > >(6) Will the MIBs for any of these routing tables be 
> capable of representing multiple independent,
> > >possibly overlapping sets of site-local routing 
> information?  I looked them over quickly, and it
> > >wasn't immediately obvious to me how they could do this.
> > >
> > >(7) Do you think that there would be some utility to 
> defining the actual routing architecture (as
> > >opposed to just the addressing architecture) for IPv6?  If 
> so, what would be the best way to do
> > >that?
> > >
> > >(8) Should we mention link-local addresses anywhere in 
> these specifications?  We certainly would
> > >not want to propagate routing information for link-local addresses.
> > >
> > >If there is some work that needs to be done here, I am 
> very happy to provide some IPv6 expertise
> > >to that effort.
> > >
> > >Margaret
> > >
> > >
> > >
> >

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Jun 2002 08:56:58 -0400

None that I am aware of?  Putting SLs in DNS is the two-face problem and at least the BIND code don't deal with this yet.  And I don't think it should ever do this IMO.
/jim

> From: Allison Mankin [mailto:[email-masked]]
> Sent: Sunday, June 09, 2002 7:50 PM
> To: Tony Hain
> Cc: Steven M. Bellovin; Pekka Savola; Ralph Droms;
> [email-masked]
> > and the 
> > only reason a DNS server should return an SL address is if 
> the query was 
> > addressed to its SL address. Maybe this needs to be stated 
> clearly in 
> > the ngtrans doc on DNS issues, but this should be obvious from the 
> > perspective of 'don't return an answer that can't be used'. 
> 
> I would question whether this is well-understood and DNS servers
> are ready to select which AAAA records to reply with depending
> on the address the query was sent to.  Do current servers implement
> this, including caching servers?
> 
> Allison
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Jun 2002 09:14:33 -0400

We have seen this for too long.  We should not wait on this SL figuring it out anymore rip them out of IPv6.
 
/jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, June 11, 2002 9:47 AM
To: [email-masked]; [email-masked]
Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols

Roy

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Jun 2002 09:06:09 -0400

let me second that and add.  Its BRAIN DEAD idea.  Sorry I view code like a child.  children with sitelocals is like children on drugs to use a randy type abstraction :--)

/jim

> Sent: Monday, June 10, 2002 11:14 AM
> To: Tony Hain
> > In any
> > case, the only way a DNS server should return a SL in a 
> response is if
> > the query was received on a SL. This is the only reasonable 
> way for the
> > server to know if the answer is usable.
> 
> it doesn't work in general, because the query could be from a cache
> that doesn't know anything about SL.
> 
> putting limited-scope addrs in DNS is a Bad Idea, period.
> 
> Keith

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Jun 2002 09:22:10 -0400

another good point.  I will have to put all this "virtual" if-then context in all the transition code. YUCK............

Come on folks lets kill them.

/jim

> From: Alain Durand [mailto:[email-masked]]
> Sent: Tuesday, June 11, 2002 3:13 PM
> To: Randy Bush
> Cc: Keith Moore; Markku Savela; [email-masked]
> On Tuesday, June 11, 2002, at 12:02 PM, Randy Bush wrote:
> 
> >> it seems obvious in hindsight that private addresses were a mistake
> >> in IPv4.  so the fact that they exist, and that we now find it 
> >> necessary
> >> to warn people to not advertise them in DNS, shouldn't be cited as
> >> a justification to make further mistakes which will then 
> necessitate
> >> further kludges to DNS.
> >
> > agree.  so let's get rid of these kinky scoped addresses in v6
> 
> That would certainly make life in v6 land much simpler.
> And anything that makes it simpler ease transition worries.
> 
> 	- Alain.
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Jun 2002 09:19:28 -0400

exactly.
/jim

> Sent: Tuesday, June 11, 2002 1:00 PM
> To: Steven M. Bellovin
> Cc: [email-masked]; [email-masked]
> > I think this is the key point.  Regardless of the possible 
> benefits of
> > site-local addresses -- and I'm willing to withhold judgment on that
> > point -- we don't know in detail how to make them work.  At 
> a minimum,
> > we need changes in routing and the DNS.  We may need new global
> > namespaces as well, with all that implies for co-ordination and
> > administrative overhead.
> 
> and given that all that stuff is "needed", and the costs 
> associated not just
> with this infrastructure but also of the increased burden on 
> applications,
> it ought to raise a strong suspicion that SL addresses are 
> not worth the cost.
> 
> Keith

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Jun 2002 09:25:56 -0400

we can keep link-local and not above.
/jim

> From: Derek Fawcus [mailto:[email-masked]]
> Sent: Tuesday, June 11, 2002 4:36 PM

---

From: "Michel Py" <[email-masked]>
Date: Thu, 13 Jun 2002 20:03:15 -0700

> Tony Hain wrote:
> There are uses for 1918, and life would have been good without NAT.
> We need to keep the real problem child in focus and not blame 1918
> for the transgressions of NAT.

I agree.

> Service providers and network managers clearly know the boundaries
> of their routing complex, and may find that using SL is a reasonable
> mechanism for SNMP and other management traffic, much as they use
> 1918 now.

SNMP is a good example. In a large network, it is desirable (for
operational purposes) to have numbered and routable addresses on each
interface and a routable loopback interface as well. The loopback
interface is used mainly for administrative and management purposes. If
it is desirable to have public addresses on interfaces (for
traceroutes), it is equally desirable to have a private address for the
loopback, as the outside world has no business with it.

Translation in the ipv6 lingo: private = site-local.

Michel.

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 17 Jun 2002 10:19:11 -0400

Also no one said get rid of 1918 that is abursd and impossible IMO.

But if we don't have to propogate this to v6 is the issue.

The logic that we should keep SLs because of 1918 is completely bogus.

/jim

> Sent: Thursday, June 13, 2002 8:24 PM
> To: Tony Hain
> Cc: Bound, Jim; Randall Stewart; Steven M. Bellovin;
> [email-masked]
> > It is time to get off this thread and back to real work. 
> Those who want
> > SL removed should get 1918 moved to historic first
> 
> complete red herring.
> 
> a socially better case of this herring would be to cure world 
> hunger first.
> 
> we may not like 1918, but that does not mean we should 
> reproduce it to show
> our dislike.
> 
> randy
>

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 17 Jun 2002 10:19:17 -0400

Mark,

That was not quite fair to Michael.  Because I use a global address does not mean I can't do what you say even with a renumbering event.

CPE - provides new prefix to edge cpe router.
Edge CPE router begats router renumbering
link router - advertises new prefix and deprecates old address 
the NFS server gracefully moves to new address.

users will have time to reconnect.

/jim

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, June 14, 2002 9:50 PM
> To: Michael Thomas
> Cc: Robert Elz; Steve Blake; Thomas Narten; [email-masked]
> > Robert Elz writes:
> >  >     Date:        Fri, 14 Jun 2002 10:26:44 -0700 (PDT)
> >  >     From:        Michael Thomas <[email-masked]>
> >  >     Message-ID:  <[email-masked]>
> >  > 
> >  >   |    But the real problem was renumbering. That
> >  >   |    still hasn't gone away.
> >  > 
> >  > No, and that's why we need these things - so when 
> renumbering happens,
> >  > our internal addresses (the ones I use to mount my 
> filesystems from
> >  > the fileserver, etc, which stay in use for months or 
> years between
> >  > reboots) don't alter.
> > 
> >    I guess I get off the merry-go-round here because
> >    I'm having a hard time imagining a deployment where
> >    it's OK to hose general internet connectivity, so
> >    long as other local services are kept up. Somehow
> >    I don't expect that the user population counting on
> >    their pr0n will be mollifed to find out that they
> >    can still download their PHB's powerpoints.
> > 
> >    YMMV.
> > 
> > 	     Mike
> 
> 	Well you have a very poor imagination and understanding of
> 	typical connection patterns.  99.99% of external connections
> 	are short lived.  Those that arn't short lived take a hit
> 	when the address renumbers.  This is why certian providers
> 	can get away with *forcing* a address change every 24 hours
> 	today.
> 
> 	However if you put a NFS server on a machine that has its
> 	address change every 24 hours then have a 10000 mounts off
> 	that server spread over 1000 machines and see what happens.
> 
> 	NFS isn't the only protocol where long running connections
> 	are the norm *inside* a site.  Things like SSH/X11/TELNET
> 	all tend to have much longer running sessions intra site.
> 
> 	Mark
> 
> Mark Andrews, Internet Software Consortium
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 17 Jun 2002 10:19:06 -0400

I will have to buy Dave a beer for this then.  Plus I would buy him a beer anyway as he is a good guy.

/jim

> Sent: Thursday, June 13, 2002 3:58 PM
> To: Bound, Jim
> Cc: Bill Fenner; [email-masked]
> > Read the latest architectural Internet doc  by Bush et al.
> 
> from the credit where due department: dave meyer was the 
> principal author
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 17 Jun 2002 10:19:15 -0400

> 
>   | Also this is not the case for link-local.  The reason is 
> that the links
>   | are hardwired in the implementation and treating them as 
> zones works for
>   | links.  But sites are "virtual".
> 
> More FUD...
> 
> Sites are only "virtual" until someone decides which links 
> belong to the
> site, and which do not, and configures things that way.

Sites can include links but of themselves do not exist they are virtual.

> 
> They're no more virtual than an ATM based link level, where 
> someone has
> to decide which ATM PVCs and SVCs perhaps are part of the 
> link, and which
> are not, and/or any modern switch where someone has to decide 
> which ports
> belong to which VLAN.

Those are virtual to and I don't believe in these networks either.  So I am being consistent.

> 
> Once configured, any and all of these things are just as real as each
> other.

If you add the logic to the routing table, src addr select, etc.  the virtual can be used yes. but many of us don't believe its worth it.  that adds code too so just put that in your calculator as we talk.

/jim
> kre

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 17 Jun 2002 10:19:12 -0400

> From: Robert Elz [mailto:[email-masked]]
> Sent: Friday, June 14, 2002 3:06 AM
> To: Bound, Jim
> Cc: [email-masked]; Michel Py; Bob Hinden; Steven M. 
> Bellovin;
> [email-masked]
>     Date:        Thu, 13 Jun 2002 08:47:49 -0400
>     From:        "Bound, Jim" <[email-masked]>
>     Message-ID:  
> <[email-masked]

> 
> We lost the possibility of end to end because we didn't have enough
> addresses for everyone.   As long as we have enough addresses that
> everyone can have one, then end to end remains.

I am saying remove any chance of private addresses unless users want to invent their own.
Or do what we did with Net 10 and not have them as part of the IPv6 scoping architecture which I believe is a technical flaw for deployment and not needed.

/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 17 Jun 2002 10:19:10 -0400

I don't agree.  Steve brought up a valid question and it is coming up again I agree.
Many are not comfortable with them.  I say we continue to hear the issues.

/jim

> From: Tony Hain [mailto:[email-masked]]
> Sent: Thursday, June 13, 2002 8:17 PM
> To: Bound, Jim; Randall Stewart; Steven M. Bellovin
> SL removed should get 1918 moved to historic first, get all products
> using that off the market, then come back and raise the 
> issue. Since we
> know that won't happen, the constructive thing to do is for those that
> don't think they can support SL to leave it out of their 
> implementation,
> while those that have figured out how to use it as a 
> differentiator can
> leave it in. Yes that might cause interoperability problems, 
> but only in
> the case where a site was running with SL as its only prefix. When a
> node doesn't support SL, it will be hard pressed to register an SL
> address in whatever name resolution system is being used, and if a
> product can't respond correctly to an SL address, an administrator
> shouldn't register it. Every node should be able to work when only a
> global address is returned, so in any realistic scenario, where is the
> interoperability problem?
> 
> On the topic of documenting when and how SL interacts with 
> DNS or SIP or
> your favorite name-to-address-mapper, yes more work is needed. I would
> argue this belongs in the DNS WGs, but if their approach is 
> to ignore it
> because it is different from current operation, then the IPv6 
> community
> will have to corner some DNS experts long enough to learn the 
> issues. In
> any case it doesn't make sense to waste time arguing that 'XYZ
> configuration will not work', when no sane network manager would
> configure a network that way. When particular configurations 
> don't work,
> pointing that out in documentation makes sense, but demanding to throw
> out the mechanism because an obscure corner case fails is not good
> engineering.
> 
> One issue that I am surprised has not been raised here is the 
> case where
> a node has administrative restrictions on which prefixes it can learn
> from an RA (specifically so that it will only work on the 
> home network),
> and that list includes SL. If that node appeared on a foreign net, it
> would ignore the globals, but would happly accept any SL and 
> may be wide
> open. One could argue that it shouldn't happen, but consider the case
> where enterprise-A uses 802.11, and a laptop with it built-in (and no
> administrative rights to the user to turn it off) were to show up at
> enterprise-B. The sys-admin may have thought the machine was 
> reasonably
> protected by the filter list on the RA, but by using SL left that node
> wide open when it was away from home. This is not an argument that SL
> shoudl be dropped, just that it is not appropriate in all contexts.
> 
> One case where it does make sense is in consumer electronics that are
> intended for local in-home use, and have no reason for global
> addressibility (say a light switch). Those who want SL removed are
> arguing that the average consumer will be required to manage 
> a firewall
> to keep the global address of the light switch from being reached
> externally. Many of them can't even get self-configuring NATs to work
> with help from a support desk, so forget any hope that they will do
> something more complex. While having the light switch accessed by a
> control unit could be done with LL, does it make sense to 
> have a control
> unit connect to every possible link technology in a home, or does it
> make more sense to use SL from a stand-alone control unit and have a
> routing device attach to the different segments? We typically define
> control and routing jobs as separate functions, so why would someone
> expect that they now magically show up in the same box? The router
> should be a cheap box with nothing but connectors, while the control
> unit has a fancy UI and may be replicated in multiple locations.
> 
> As I scan through this thread, it started by questioning the lack of
> documentation about how SL should work in a particular context, but
> quickly degraded into an attack on change. The IETF is about managing
> the consistent change that has been taking place in networking, so
> standing up and saying 'take this out because it requires us to change
> the way we have done it forever' is counter to our role. Documenting
> that a mechanims works in configuration A, not at all in configuration
> B, and we haven't figured out configuraion C, is what we need to do
> here, so lets get on with it.
> 
> Tony
> 
> 
> 
> Jim Bound wrote:
> > As all know I wanted these dreaded site-locals gone since we
> > invented them in IPv6.
> > This has been discussed before if we can revisit this again
> > that is a very good thing.
> > Steve and Randy are 100% correct.
> >
> > I would also add they break lots of stuff.
> >
> > /jim
> >
> > > From: Randall Stewart [mailto:[email-masked]]
> > > Sent: Thursday, June 06, 2002 2:46 PM
> > > To: Steven M. Bellovin
> > > Steve:
> > > Having implemented SCTP and IPv6 together I could not 
> agree with you
> > > more.
> > > I know in our work on scoping of addresses it got very very
> > tricky on
> > > attempting to figure out which set of addresses to tell the other
> > > SCTP endpoint about to avoid black hole conditions. So in the end
> > > the only way you could handle it is if the destination address
> > > of your INIT packet (consider it a SYN) was TO a site-local then
> > > you could include your site-locals... This means that if the user
> > > sent the INIT to the global address then the peer NEVER
> > gets informed
> > > of site locals.... maybe something not desired but unavoidable...
> > >
> > >
> > > Now with the new addition of site-scoping even this will 
> break since
> > > one must all of a sudden be cognizant of what site the peer
> > is on and
> > > only send a sub-set of the site-local addresses (gak!!).
> > >
> > > In all of this I have tried to figure out what use these 
> site locals
> > > are?
> > >
> > > If I have a global address why would I ever want to use a
> > site-local?
> > > If no global-addresses are available and I am not attached to the
> > > public inter-net I could possibly see using a 
> site-local.. maybe but
> > > I would think this is more the 'dentists' office scenario where in
> > > link-local will suffice... If the 'dentist' wants to talk to the
> > > insurance company I doubt that it would be in the
> > 'dentist's' site...
> > > so he would need a connection to the global address 
> space... and the
> > > problem goes away....
> > >
> > > Only in a large company would I see a site-local being
> > applied.. but
> > > in such a company why not just use a global address? What does it
> > > buy me to have this extra address? I already know my
> > assigned address
> > > space... I can have my company border routers prevent spoofing of
> > > my address into my network... so I can use the source being the
> > > global address that is assigned to me to "know" that I am in the
> > > same company...if thats what I want...
> > >
> > > I may be able to see (maybe) that a large company wants to NOT
> > > connect to the global address space... so here site-local MIGHT be
> > > something I could use... but adding in scoped site-locals I
> > just can't
> > > see a use for... It just causes all sorts of fun problems.
> > >
> > > I would much rather see the company that is NOT going to want to
> > > connect to the global address space just have a way to get some
> > > global address space.... I realize with the current number scheme
> > > this is not possible so maybe a site-local does make sense in
> > > this one strange instance... but in this case the company
> > > does not need
> > > to worry about global mixed with site-local :>
> > >
> > > So maybe site-local (if allowed) should only be valid if NO global
> > > address is defined :>
> > >
> > > R
> > >
> > > "Steven M. Bellovin" wrote:
> > > >
> > > > In message
> > > <[email-masked]>, 
> Margaret Wasserm
> > > > an writes:
> > > > >
> > > > >the responses after this one.  I suppose I just should
> > > have cc:ed the IPv6 gro
> > > > >up in the
> > > > >first place...
> > > > >
> > > >
> > > > Margaret has pointed out that our routing protocols 
> don't support
> > > > site-local addresses.  The only alternative suggestion I've
> > > seen thus
> > > > far is to run multiple instances of, say, OSPF on all
> > > routers within a
> > > > site.  But how are these distinguished from each other?
> > > OSPF runs with
> > > > an IP protocol number, not a port number, so we can't
> > have multiple
> > > > instances that way.  And RFC 2740's specification of 
> the necessary
> > > > multicast addresses notes that they're all link-local.
> > > Still, there's
> > > > apparently running code; I look forward to seeing the details.
> > > >
> > > > I'm very concerned about DNS entries.  When should a DNS
> > > server -- or a
> > > > caching resolver -- return a site-local address?  (If the
> > DNS never
> > > > returns such things, they're useless.)  One suggestion
> > I've heard is
> > > > two-faced DNS servers -- only return site-local 
> information if the
> > > > querier is within the same site.  Apart from the fact
> > that I have no
> > > > idea how that determination can be made -- surely no one
> > > will suggest
> > > > putting site-local addresses into NS records -- RFC 2182
> > > (aka BCP 0016)
> > > > specifically warns against putting all secondary servers
> > for a zone
> > > > within a site:
> > > >
> > > >    Consequently, placing all servers at the local site,
> > > while easy to
> > > >    arrange, and easy to manage, is not a good policy.
> > > Should a single
> > > >    link fail, or there be a site, or perhaps even
> > building, or room,
> > > >    power failure, such a configuration can lead to all
> > servers being
> > > >    disconnected from the Internet.
> > > >
> > > >    Secondary servers must be placed at both topologically and
> > > >    geographically dispersed locations on the Internet, to
> > > minimise the
> > > >    likelihood of a single failure disabling all of them.
> > > >
> > > > Etc.
> > > >
> > > > There will also be a lot of unnecessary pain in DNS 
> maintenance as
> > > > "sites" are split or merged.  v6 is designed to support
> > > easy renumbering
> > > > of global addresses, but those are designed to reflect topology.
> > > > Site-local addresses do not, which increases the probability of
> > > > address space collision during a merger.
> > > >
> > > > Philosophically, I think that the problem is that a
> > "site" is a new
> > > > (and deliberately poorly defined) concept.  The DNS is
> > > designed to work
> > > > with administrative boundaries, while routing and
> > addressing reflect
> > > > topology.  We now have a new concept that is neither
> > > administrative nor
> > > > topological, but one that must be supported by 
> administrative and
> > > > topological mechanisms.
> > > >
> > > >                 --Steve Bellovin,

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 17 Jun 2002 10:19:12 -0400

the markets for v6 and v4 are different not the same.
/jim

> Sent: Thursday, June 13, 2002 8:51 PM
> To: Randy Bush
> Randy Bush wrote:
> They are designed to serve the same purposes. Clearly the market has
> found several uses for 1918, so claiming any of those (except 
> expanding
> the address space by reuse) are void in an IPv6 world is a 
> bit academic.
> 
> >
> There are uses for 1918, and life would have been good without NAT. We
> need to keep the real problem child in focus and not blame 
> 1918 for the
> transgressions of NAT.
> 
> Service providers and network managers clearly know the boundaries of
> their routing complex, and may find that using SL is a reasonable
> mechanism for SNMP and other management traffic, much as they use 1918
> now. The issues raised on the thread have mostly focused on 
> cases where
> the site boundary is not clear. When there is no clear 
> boundary then SL
> shouldn't be used, just as you can't use 1918 in those cases now.
> 
> Tony
> 
> 
>

---

From: "Michel Py" <[email-masked]>
Date: Tue, 18 Jun 2002 08:47:08 -0700

> Michael Thomas wrote: 
> Requiring hosts to have knowledge of network topology
> is a bug, not a feature.

I agree, but there would be ways to use SL by having them handled by the
routers only, with a routing protocol.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Wed, 19 Jun 2002 08:08:45 -0700

> - Making site-local implementation optional? Maybe hosts that
> don't implement SL should treat them as global, routers should,
> by default, never forward them? -- This opens the possibility
> of enabling site-local later with changes only in routers.

I have to say that using SLs on a v6 portable phone would not be my top
priority if I was developing such a product. It seems that all the
perceived need for SLs is for fixed hosts on relatively large setups.
What about a clause making the implementation optional for mobile
devices?

Michel.

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 19 Jun 2002 23:01:44 -0400

I agree with Tim for the record.  If we do this below that at least is a way forward.
If we are to have them I would like to know what the MUSTs are too and also I agree the min is in rich draves src addr select.

/jim

> From: Tim Hartrick [mailto:[email-masked]]
> Sent: Wednesday, June 19, 2002 6:57 PM
> To: [email-masked]; Bound, Jim
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Jim,
> > Site identification requires a site-zone-id to 
> differenentiate fec0::1 from fec0::1 on a node with two 
> sites.   Under the site-identifier for the two sites are 
> local links that also require zone ids for the link-locals.  
> > 
> > So the structure for an interface requires site-zone-id and 
> then within each site link-local-zone ids.  
> > 
> > What I am saying is the site-id abstraction now requires 
> another level of indirection when determining which interface 
> the packet should be sent for interface data structures, 
> routing data structures, and tansport data structures.  It 
> also requires more intelligence for SCTP as example that uses 
> addresses as failover in this case.  For site-local just the 
> addresses is not enough but also the site-id now.
> > 
> > Rather than debate site-local existence maybe it would be 
> good to just get consensus on their complexity and what they 
> mean regarding added work for implementations?  
> > 
> 
> I think that this is the right direction to go and I agree 
> with Jim that the
> vast majority of the implementation complexity associated with limited
> scope addresses is associated with nodes that are connected 
> to two or more
> zones.  Given this, I don't see any reason that individual 
> implementors can't
> decide for themselves, based on customer demand, whether or not their
> implementation needs to be able to support being connected to 
> two or more zones.
> This, in my opinion, goes for link-local, site-local or any 
> future limited scope
> unicast address that can be imagined.
> 
> The existence of site-local addresses in the address 
> architecture doesn't
> imply a requirement that every implementation be able to act 
> as a site-border
> router or implement "two-faced" DNS or implement various 
> unspecified routing
> protocol extentions to implement site-border router 
> functionality.  All of
> these features are admittedly complex to specify and 
> implement, but not
> impossible given appropriate motivation.  The good news is 
> that not every
> implementation needs to have all these features from day one. Most
> implementations will never need any of them.
> 
> There are a minimum set of requirements that any node will 
> have to implement
> in order to communicate using site-local addresses.  As far 
> as I can tell that
> minimum set is pretty well specified in the Draves 
> destination/source address
> selection draft.  Any specification and implementation beyond 
> that minimum
> set should be driven by customer demand.
> 
> What I would like to see come out of this long discussion is 
> simply some text
> in the in progress "Node Requirements" document that 
> specifies how much of the
> scoped address architecture MUST be implemented and that that 
> text would say
> that the rules specified in Draves' draft are the only MUST 
> implement portion
> of the architecture.  There should be no requirement that a 
> node be able to be
> part of more than one zone.
> 
> The above should solve. in the near term, the fears of implementation
> complexity.  The "architectural" arguments against 
> site-local/private addresses
> can't be countered except to say, as many others have, that 
> customers will use
> "private" address space.  It is going to happen.  Something 
> like RFC 1918 will
> come into existence.  We can specify the bit pattern now or 
> specify it later,
> but it will be specified.  It is indeed scary that this might 
> lead to IPv6 NAT
> but IPv4 NAT happened without any RFCs or architectural 
> blessing.  Removing
> site-local addresses from the address architecture will do 
> exactly nothing to
> stop IPv6 NAT if the reasons that IPv4 NAT exists persist; 
> address scarcity
> and cost, and questionable security capabilities.  The first 
> reason is solved
> by IPv6 as long as the providers do the right thing.  The 
> second part is mostly
> FUD which can be countered with some BCP or informational 
> RFCs, and secure
> products.
> 
> 
> 
> Tim Hartrick
> Mentat Inc.
>

---

From: "Michel Py" <[email-masked]>
Date: Tue, 25 Jun 2002 07:48:34 -0700

Brian,

>> Michel Py wrote:
>> There are other models being developed, have a sneak preview at:
>> http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt

> Brian Carpenter wrote:
> Nobody doubts that we have enough addresses to allocate them
> geographically. What we don't know is how to route them
> geographically, so I confess that I fail to see the value of
> compiling long lists of numbers.

The associated drafts are coming in a matter of days, stay tuned.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Thu, 27 Jun 2002 14:12:04 -0700

> Tony Hain wrote:
> I was not arguing against SLs with site-ids, just that we should
> not try in any way to lead people down the path where those
> site-ids are perceived to be globally unique.
> As long as the site-id is a locally administered value, a network
> administrator can use them privately in any way he sees fit,
> including private connections to other networks (assuming they can
> coordinate amongst themselves to avoid collisions).
> My primary concern is that we avoid building what amounts to an
> address registry of global scope, which ends up maximizes entropy
> in the routing system.

I agree, but you would have to restrict to a very few the number of bits
that are locally administered. If there are 16 bits to play with, it
won't take long to figure out that filling them with the AS number does
indeed make a globally unique "local" address without even a need for
coordination to avoid collisions.

> Yes we need PI public space, see: draft-hain-ipv6-pi-addr-use-02.txt
> for some of the reasons why.

This text is excellent. Tony and I are following different paths on the
resolution, but the reasons remain the same.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Thu, 27 Jun 2002 15:47:22 -0700

>> Brian E Carpenter wrote:
>> For the record, you've yet to persuade me that these schemes are
>> aggregatable in the real world of competitive ISPs.

> Tony Hain wrote:
> I understand the concern, but it comes down to a matter of
> cost/benefit tradeoff. If a geo scheme turns out to be cheaper to
> maintain than an ever expanding table full of holes, it will be
> deployed. The task at hand is finding *any* scheme that will
> create provider independent addresses in an operationally sound
> way.

Agree with Tony.

Brian, I don't expect a miracle in terms of aggregation initially. ISPs
will aggregate only if they find a gain in it. But if there is a gain,
they will.

If your concern is that they will not cooperate because they would not
want to announce a prefix that contains addresses that belong to their
competitors, I have addressed it in a reply to kre a few minutes ago.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Fri, 28 Jun 2002 18:56:57 -0700

> I am waiting to see how this is going to be achieved.  That is,
> all of what you're promising in this message.   So far, from what
> I have seen, I don't see how it can be done.

One of the drafts is ready
http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt

> But maybe there's something out there that I just don't
> understand yet.

Feel free to ask any questions you wish on ipv6mh. I have heard a lot of
"it does not work" and none explaining why.

> The aim is a /48 for everyone (who requests one), right?

At this point the aim is at multihomers only. If successful, the scheme
could be extended to everyone and / or /64s but I'd rather have a
slow-start.

> Yes, there could be a protocol, with all kinds of things.  And it
> can be turned off, or replaced, if it gets in the way.

With a lot of work if it is built into the core of the protocol.

> It isn't possible to enforce anything by relying upon protocols,
> we have to depend upon agreements, and when appropriate "it is
> the only possible way".

I have to disagree with this. If by _design_ these geo prefixes are not
in the global routing table, the only leaks could be because of
configuration snafus.

> The way we enforce aggregation now, isn't because there's some magic
> in BGP that requires it, it is because we know of no other way to
> make routing work.

Now.

> As long as that remains true, we don't have to create protocols
> to enforce aggregation in IPv6 - it will just naturally be enforced,
> because no-one can figure out how to not enforce it (nb: it doesn't
> really matter if a few stray /48's or even /128's "pollute" the
> global tables - remember the aim is to keep routing working, not to
> enforce the rule just because it is a rule). If the assumption ("we
> know no way") ceases to be true, then there's no reason at all that
> what we currently consider to be non-routable addresses shouldn't
> appear in the routing tables.  Ie: as soon as it is possible to put
> them there, any policy aimed at keeping them out no longer has a
> purpose, and should be scrapped.

I agree for the most part. However, what you are talking about more or
less requires replacing BGP. Given the time it will take, we do need a
solution in-between though.

Michel.