Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt

From: "Michel Py" <[email-masked]>
Date: Wed, 7 Aug 2002 22:48:44 -0700

Margaret,

> Margaret Wasserman wrote:
> Having made the mistake of jumping into this swamp,
> I guess I'll keep swimming...

To be honest, I think it was about time that this issue came to a head.
Because the issue is not about /127 prefixes, but it is about the
reading of [addrarch] that says (or does not) that a prefix longer than
/64 is not to be used for anycast addresses.

> But, first let me point out, as a WG chair, that the
> addressing architecture is a WG document with a long
> history of compromise and consensus.

This is very, very true.

> No significant changes will (or should) be made to the
> addressing  architecture based on my personal opinions,
> even if a few other people agree with me. It would require
> a consensus of the WG to change the addressing architecture
> in the ways that I have suggested.  We have discussed these
> things before (on the mailing list and in person) and, so
> far, there has been no WG consensus to make these sorts
> of changes.

This is fair.

Back to Pekka's draft: I think it would be fair to say that Pekka's
draft is valid if [addrarch] is _not_ to be modified, and needs to be
dumped if [addrarch] is to be modified.

> This is a holdover from the 8+8/GRE discussions that we had a few

I assume you meant GSE, not GRE.

> For a large number of documented reasons, we chose not to
> pursue the 8+8/GRE mechanism.  But there were a substantial
> number of people (I was one of them) who thought that it was
> important to maintain the global uniqueness of the IID, so
> that we might later be able to pursue such a mechanism.

I don't think this has changed. This might sound a paradox, but here it
is anyway:
As the author of a protocol (MHAP) that has been compared to 8+8/GSE
many times (with or without reasons) and that actually does address the
issue of the uniqueness of the IID, I still think that it is not wise to
close this door although I have myself provided an alternative way out.

In other words: I personally don't care about the 'u' bit, but now is
not the time to close doors as long that big unknown about multihoming
is not settled.

> Personally, I think that it is highly unlikely that there
> will be any benefits to being able to separate the
> identification and topological routing information for
> _some_ hosts.

I hope you don't mind my bluntness, but you don't know yet; nobody does.
Now is not the time to close doors.

> I have been told, though, that there are still a
> significant number of people who believe that the 'u'
> bit should be maintained for later use in a system that
> separates ID and routing goop (as it was called in
> GRE). These people were reportedly willing to accept the
> compromise of splitting the address space into two portions
> (via the 'u' bit), one that would have unique IIDs and one
> that would not.  If there are folks who still believe that
> this is a valuable property, could you please speak up in
> support of it, and explain why?

As mentioned above, now is the time to keep our options open. I hope
that this counts as a valid opinion, as my personal agenda actually goes
against what I recommend we do WRT this matter, which is that we
actually keep the 'u' bit for the time being.

> At that time, it didn't seem like a big issue to add a
> hard /64 boundary into the IPv6 address, because we already
> had several hard boundaries in our addresses to provide
> separate fields for aggregation (the TLA/SLA stuff). Since 
> then, we have removed the other hard boundaries and moved
> to a CIDR-like address structure, but we have maintained the
> hard /64 boundary, and required Modfied EUI-64 IIDs for all
> global unicast addresses.

Note about this: My reading is that there still is a semi-hard boundary
at /48, (site) and I think this is good.

> But, what I think this WG needs to think about and understand
> is _why_ operators are using longer prefixes on their
> router-to-router links. Is this just because that's how it has
> always been done?

There is a large part of this. I peer with both /127s and /64s. Both
work fine. The issue here is *not* I repeat *not* whether or not /127s
or /126s are suitable for ptp links. I support Pekka's draft saying that
/127s are not good, but /126s or /112s are technically usable.

Recently, I peered with John Fraizier. I don't think that there was any
questions about using a /64 for the tunnel (John, please comment as
needed). I also setup private peerings with buddies and there again we
used /64s.

That being said, the issue again is *not* about it. The issue is: can we
finally get everyone to go in the same direction?

Among many others, kre and I have debated over and over the issue. None
of us is wrong, and none of us is right. Let's put an end to this and
settle it. We have more important things to do.

> - A router can easily know the address of the router on the
> other end of the link...  What is this used for? How valuable
> is this?

This is worth its weight in gold. Look at an IPv4 example:

Your router's address is x.y.x.33 /30. What is the other end (coz you
want to ping it to see if the circuit is up)? It's x.y.z.34. I don't
need a calculator for this, but the NOC dude that picks up the phone at
3 am does, and still will get 50% wrong and try to ping x.y.z.32 :-((

IPv6 example: Your router's address is x:y:z:t::1/64. What is the other
end? Mmmm. Let's try x:y:z:t::2/64.

As I said above, it all comes to this:
Do we have a consensus about modifying [addrarch]?

Yes -> Let's modify it.
No  -> Let's move Pekka's draft to Informational or BCP and settle this.

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: Pekka Savola <[email-masked]>
Date: Thu, 8 Aug 2002 09:14:10 +0300 (EEST)

> /64 is not to be used for anycast addresses.

No.
 
> dumped if [addrarch] is to be modified.

This is incorrect; there are two issues here:

 1) addrarch statements about /64 which make the use of longer than /64 
"forbidden"
 2) people still using /127 and in future experiencing problems due to 
subnet router anycast address.

The point of my draft has *ALWAYS* been 2).  It's not an advocacy document
(point 1) above), even though people have tried to make it one (and I must
admit I've given in an inch or two).

> work fine. 

Your routers probably don't support subnet router anycast address.

> The issue here is *not* I repeat *not* whether or not /127s

There are two issues, as stated above.

> No  -> Let's move Pekka's draft to Informational or BCP and settle this.

There are other options also.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Robert Elz <[email-masked]>
Date: Sat, 10 Aug 2002 18:39:47 +0700

Date:        Wed, 7 Aug 2002 22:48:44 -0700
    From:        "Michel Py" <[email-masked]>
    Message-ID:  <[email-masked]>

  | To be honest, I think it was about time that this issue came to a head.
  | Because the issue is not about /127 prefixes, but it is about the
  | reading of [addrarch] that says (or does not) that a prefix longer than
  | /64 is not to be used for anycast addresses.

You mean unicast.

  | Back to Pekka's draft: I think it would be fair to say that Pekka's
  | draft is valid if [addrarch] is _not_ to be modified, and needs to be
  | dumped if [addrarch] is to be modified.

Not dumped.  Modified probably.   That is, that we allow prefixes of
any length does not by itself mean that using /127 (which is what the
draft is arguing against) is rational.   I'm not convinced it is
irrational (not as convinced as Pekka anyway) but on the other hand
I find it very hard to come up with any convincing reason for actually
using /127's.   /112 allows me plenty of address space...

  | In other words: I personally don't care about the 'u' bit, but now is
  | not the time to close doors as long that big unknown about multihoming
  | is not settled.

OK, since you're the first person (I have seen anyway) willing to actually
claim that this just potentially might be useful, please explain how
it can ever work.

Forget the multihoming use of the thing, just explain how your implementation
would ever set the 'u' bit in a way that you're able to guarantee (enough)
global uniqueness that multi-homing (or anything else) would ever be able
to rely upon it.

Knowing that it is possible to use the thing as proposed this way would
go a long way toward justifying retaining the 'u' bit as defined (and if
'u' is to be retained, then we need /64 as well, because of where the 'u'
bit is positioned - if we were doing this rationally, we'd have reordered
the bytes in the addresses, and made 'u' appear in the least significant
octet of addresses, rather than splat in the middle).

At least then we could have a reasoned cost benefit analysis.  At the
minute I don't believe it is even possible to use the 'u' bit for this
kind of purpose, regardless of how attractive it might be to be able to
do it for some application or other.

  | I hope you don't mind my bluntness, but you don't know yet; nobody does.
  | Now is not the time to close doors.

Perhaps not (though this WG has been entirely willing to rule out all kinds
of other things for which an immediate application hasn't been shown).

But before we argue for leaving the door open, can we perhaps determine
whether or not it has already closed?   (slammed and double locked...)

  | Note about this: My reading is that there still is a semi-hard boundary
  | at /48, (site) and I think this is good.

Please keep in mind what the boundaries are for.  The /48 is an allocation
size (there are also /32 and /16 and /3 that apply in that realm).
That's all OK, those numbers can always be changed, almost without thought,
as nothing, other than the allocation system depends upon them.
We just tell the registries to allocate /32 instead of /35, and they
do that (maybe they argue a bit, or something, but this is all just
politics etc).

This is totally different from any boundaries in addresses that can be
observed or predicted by other nodes.   That's the one we need to do
away with.

We're always going to have all kinds of allocation boundaries, we should
never have any boundaries that can be observed in someone else's addresses.

  | Among many others, kre and I have debated over and over the issue. None
  | of us is wrong, and none of us is right. Let's put an end to this and
  | settle it. We have more important things to do.

That would be nice.   Unfortunately, I dont think this is just a coin
toss issue - that is, one where a decision is needed, but any decision
will do.   There actually is right and wrong here.

kre

---

From: Thomas Narten <[email-masked]>
Date: Mon, 12 Aug 2002 15:48:48 -0400

> at /48, (site) and I think this is good.

If you are talking about addrarch, please point out the words that
lead you think this. There is *no* technical hard boundary at
/48. There is a *policy* or *allocation* boundary, and there are
technical reasons why such a boundary make sense, but implementations
should not have any sort of /48 boundary hard-wired into the code.

Thomas