Subject: RE: GUSL / GUPI summary

From: "Michel Py" <[email-masked]>
Date: Thu, 5 Dec 2002 14:47:44 -0800

> Margaret Wasserman wrote:
> I am not sure that we have general agreement that there
> should be two courses.  I, for one, do not think that
> we should create two different types of addresses...

Now you got me lost. If you say site-locals should not be used for
external connectivity, how are you going to do GUPIs without creating
another type of address?

Michel.

--------------------------------------------------------------------
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: Fri, 06 Dec 2002 09:32:20 -0500

Hi Michel,

It is my personal opinion that we should leave site-local addresses
as-is and strictly limit their use to completely disconnected, isolated
networks.

I also think that we should work on a way to offer provider-
independent IPv6 addressing, but I think that these should be
global addresses, not site-locals.  While it is possible that ISPs
will not advertise these addresses in global routing tables, I do
not think that they should be limited to a "site", or treated as
scoped addresses (with zone IDs, etc. as in the scoped addressing
architecture).  I think that they should be global addresses that
may be filtered at administrative boundaries (and _will_ be filtered
at some boundaries, if we can't find an aggregable way to allocate
them).

I do not, personally, think that we gain much by trying to improve
current site-locals to be more unique.

Margaret

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 6 Dec 2002 17:44:31 -0800

Margaret Wasserman wrote:
> It is my personal opinion that we should leave site-local 
> addresses as-is and strictly limit their use to completely 
> disconnected, isolated networks.

1) It is not possible for the IETF to restrict their use to completely
isolated networks. 

2) It is not a requirement that a connected network not use them.

The only reasonable argument here is that the IETF may choose to leave
the details of such use undocumented, and not spend time addressing the
DNS issues.

> global addresses, not site-locals.  While it is possible that 
> ISPs will not advertise these addresses in global routing 
> tables, I do not think that they should be limited to a 
> "site", or treated as scoped addresses (with zone IDs, etc. 
> as in the scoped addressing architecture).  I think that they 
> should be global addresses that may be filtered at 
> administrative boundaries (and _will_ be filtered at some 
> boundaries, if we can't find an aggregable way to allocate them).

I agree with the need for PI, and for those who would like to provide
comments, the current state of the updates to my approach can be found
at:
http://www.tndh.net/~tony/ietf/ipv6piaddressformat-04.txt & 
http://www.tndh.net/~tony/ietf/ipv6piaddressusage-04.txt
I found a way to change the grid sizes and origin so now all of Europe
is in one logical grouping.

> 
> I do not, personally, think that we gain much by trying to 
> improve current site-locals to be more unique.

We might provide an informational document that provides guidance to
sites to randomize the upper 38 bits to avoid potential problems with
mergers later. We don't need to specify a standard mechansim, but might
suggest a couple of reasonable stratigies.

Tony

> > > I am not sure that we have general agreement that there should be 
> > > two courses.  I, for one, do not think that we should create two 
> > > different types of addresses...
> >

---

From: Keith Moore <[email-masked]>
Date: Fri, 06 Dec 2002 21:29:46 -0500

> 1) It is not possible for the IETF to restrict their use to completely

yes, but it is possible for IETF to recommend that their use be so 
restricted, which is what I assume Margaret was suggesting.

all IETF standards are just sets of recommendations.  but just like with any 
other aspect of a standard, if a network or host or app chooses not to 
follow the recommendation, it's not guaranteed to work well, or at all.  
 
> 2) It is not a requirement that a connected network not use them.

no, it's just a good idea for connected networks to not use them,
and this is also something that IETF could recommend.

> the details of such use undocumented, and not spend time addressing the

we know that use of SLs without restrictions will cause problems.  
it's not reasonable to pretend otherwise or to fail to disclose those 
problems.  
nor would it be consistent with the rfc 2026 requirements for standards.

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 07 Dec 2002 05:28:02 -0500

Hi Tony,

>1) It is not possible for the IETF to restrict their use to completely

I realize that the IETF cannot enforce such a restriction.  But, we
can write a standard that says "these addresses are intended for use
on isolated networks and must not be used on non-isolated networks"
(or equivalent).  We can also document the problems that are likely
to occur (presumably in a companion Info or BCP document) if
site-local addresses are used on connected networks.  I am working
on a document that outlines the problems and recommends placing
limits on the IETF-advocated/supported use of site-locals, and I
believe that others are working on alternative proposals.

>2) It is not a requirement that a connected network not use them.

I'm not sure what you mean...

>the details of such use undocumented, and not spend time addressing the

Actually, I think it would be quite reasonable for the IETF to
provide a strong recommendation against using site-locals on
connected networks, and to document the problems that they cause.

>suggest a couple of reasonable stratigies.

I wouldn't try to stop this sort of approach if others think it is
valuable.  I just don't think that it solves the larger problems
caused by site-local addresses, and I'm not sure that its benefits
are worth the effort.  Real PI independent addresses are the only real
solution to this problem, IMO.  So, I'd like to see if we can find
a way to provide PI addresses in IPv6.

I have been thinking about this topic a lot lately, and I have
been refining my thinking...

In order to provide real PI addresses, we have both a policy issue
and a technical issue, both of which need to be solved.

The policy issues is that registries are currently set-up to provide
addresses to service providers for further delegation to customers
(enterprises, homes, etc.).  In order to supply PI addresses, this
would have to change.  I don't know what type of difficulties would
arise in making this change -- address allocaton policy isn't
something I know very much about, but I guess I'll have to learn.

The technical issue is that we don't want to allocate non-aggregable
addresses that will show up in the global routing table.  Tony, you
seem to have a good start on one approach to solving this problem.
Are there other well-developed proposals?  What are the current
issues/weaknesses to your approach that will need to be resolved
before it is workable, if any?

Margaret

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 9 Dec 2002 15:26:19 -0800

Margaret Wasserman wrote:
> ...
> I realize that the IETF cannot enforce such a restriction.  
> But, we can write a standard that says "these addresses are 
> intended for use on isolated networks and must not be used on 
> non-isolated networks" (or equivalent).  

My concern is the choice of 'must' rather than 'should'. SL works
perfectly fine for networks attached to the Internet when used by
2-party apps following addr selection rules. Stating 'must not' is silly
when there is a clear case where they work.

> We can also document 
> the problems that are likely to occur (presumably in a 
> companion Info or BCP document) if site-local addresses are 
> used on connected networks.  I am working on a document that 
> outlines the problems and recommends placing limits on the 
> IETF-advocated/supported use of site-locals, and I believe 
> that others are working on alternative proposals.

Just be careful not to legislate against the 2-party case that most
people will find useful and works just fine.

> I'm not sure what you mean...

Claiming that they must not be used on a connected network means we know
they will always fail, or the problems are significantly greater than
the value. We have a couple of examples of great value with no cost.
These don't impact the greater Internet, so we shouldn't be telling
people 'must not'. 

> Actually, I think it would be quite reasonable for the IETF 
> to provide a strong recommendation against using site-locals 
> on connected networks, and to document the problems that they cause.

I agree that a BCP about the issues caused to multi-party apps is
needed, and have said so several times. That does not translate into a
need for a strong recommendation not to use them on connected networks. 

> I wouldn't try to stop this sort of approach if others think 
> it is valuable.  I just don't think that it solves the larger 
> problems caused by site-local addresses, and I'm not sure 
> that its benefits are worth the effort.  Real PI independent 
> addresses are the only real solution to this problem, IMO.  
> So, I'd like to see if we can find a way to provide PI 
> addresses in IPv6.
> 
> I have been thinking about this topic a lot lately, and I 
> have been refining my thinking...
> 
> In order to provide real PI addresses, we have both a policy 
> issue and a technical issue, both of which need to be solved.
> 
> The policy issues is that registries are currently set-up to 
> provide addresses to service providers for further delegation 
> to customers (enterprises, homes, etc.).  In order to supply 
> PI addresses, this would have to change.  I don't know what 
> type of difficulties would arise in making this change -- 
> address allocaton policy isn't something I know very much 
> about, but I guess I'll have to learn.

It depends on the mechanism we end up with. My approach does not require
the registries to be involved in general, but does have a database role
for them if that proves to be useful.

> 
> The technical issue is that we don't want to allocate 
> non-aggregable addresses that will show up in the global 
> routing table.  Tony, you seem to have a good start on one 
> approach to solving this problem. Are there other 
> well-developed proposals?  What are the current 
> issues/weaknesses to your approach that will need to be 
> resolved before it is workable, if any?

The only non-FUD comment I have heard is that the current business
relationship between the exchange points and transit providers does not
fit with the plan. While I am not trying to mandate a change in business
practice, business relationships do evolve over time. I believe it is
reasonable to expect that with a supporting techincal approach, the
motivation will exist for that issue to take care of itself. 

The other significant issue with the approach had been the
less-than-elegant handling of Europe through prefix pairs (east & west
of 0). With the last pass, that was fixed so that the problem moved to
Alaska & Hawaii (which are now more closely associated with Tokyo than
Chicago). Since dealing with this is just a couple of exception prefixes
rather than the set necessary to fix Europe, it should be more
acceptable.

I haven't received any comments on the current state of the update, but
wouldn't expect too many until it goes out as the -04 ID, probably in
Jan. 

There are other proposals in varying states of completeness, so we could
have a lively debate about the trade-off's of each next year. 

Tony

---

From: "Digambar Rasal" <[email-masked]>
Date: Wed, 11 Dec 2002 16:53:18 +0530

We usually specify Ipv4 subnet like 255.255.255.0 or /8 so . But in Ipv6
while mentioning address we specify it /64 or /48 .

Does both representation have same meaning ? More specifically i will like
to know whether the Ipv6 subnetting is similar to ipv4 or differs ? Any RFC
or document pertaining to this ??

Digambar Rasal
ControlNet India Pvt Ltd
India.
+918322883601

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 11 Dec 2002 13:04:25 +0100

Digambar Rasal wrote:

> We usually specify Ipv4 subnet like 255.255.255.0 or /8 so . 
> But in Ipv6 while mentioning address we specify it /64 or /48 .

You might lookup the word 'CIDR' or Classless Inter Domain Routing.
In the /x, the x represents the number of bits for the part of the
address that describes the network. 

> Does both representation have same meaning ? More 
> specifically i will like to know whether the Ipv6 subnetting is
similar to ipv4 or 
> differs ?

No they 'work' the same. Classful (A, B, C, D, E) have been dropped
for some time already and are replaced with their CIDR counterparts.
Thus for this part of IPv4 vs IPv6, it's just a much longer address.

> Any RFC or document pertaining to this ??

www.faqs.org -> CIDR

Don't know the thing by number or name though ;)
Most current books and documents should be using it as CIDR has
been here since 1991 or something (or even earlier?).

Greets,
 Jeroen

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 11 Dec 2002 06:44:51 -0500

Hi Digambar,

>while mentioning address we specify it /64 or /48 .

As you may already know, a subnet mask of 255.255.255.0 is actually
a /24.  This means that the first 24 bits of the address contain
the routing information (the network and subnet identifiers) and the
last 8 bits contains the host identifier.

In IPv6, addresses are 128 bits long.  Writing out a subnet
mask in the long form would look something like this:

FFFF:FFFF:FFFF:FFFF:0:0:0:0

That would be awfully cumbersome, so we don't use that notation,
only the /NN notation.  So, if the first 64 bits of an address
contain the routing information (called a routing "prefix" in
IPv6), we would say that it is a /64 prefix.

>or document pertaining to this ??

IPv6 subnetting is basically identical to IPv4 subnetting.

The addressing architecture document describes this in more
detail.  The latest version can be found at:

http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-11.txt

Regards,
Margaret