Subject: RE: Review of "Use of /127 Prefix Length Between Routers Considered Harmful"

From: "Michel Py" <[email-masked]>
Date: Tue, 11 Jun 2002 22:49:35 -0700

I would say "Should become a working group draft and receive
formal review by the w.g.". I agree with the draft, but it has not been
debated much and deserves some review before giving it a nod.

Michel.

A request has been made by the author to the RFC editor to publish the 
following draft as an Informational RFC:

         Title           : Use of /127 Prefix Length Between Routers
Considered
                           Harmful
         Author(s)       : P. Savola
         Filename        : draft-savola-ipv6-127-prefixlen-03.txt
         Pages           : 5
         Date            : 20-May-02

Earlier versions of this draft have been discussed on the mailing list,
but 
it is not a working group draft.  The IESG has requested that the IPv6 
working group review the draft.  Possible outcomes of the review are:

  - OK to publish as is
  - Needs to have a few issues fixed before publication
  - Should become a working group draft and receive formal review by the
w.g.
  - Incorporate into another IPv6 w.g. document with broader scope.
  - Harmful, should not be published.

Please send comments to the list.

Thanks,

Bob Hinden, Steve Deering, Margaret Wasserman
IPv6 w.g. Co-Chairs

--------------------------------------------------------------------
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]
--------------------------------------------------------------------

--------------------------------------------------------------------
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: Wed, 12 Jun 2002 09:39:50 +0300 (EEST)

> debated much and deserves some review before giving it a nod.

This was discussed quite extensively back in Nov 2001 or so.  Afterwards
when first drafts were produced, there was some additional discussion too 
(as you know :-).

Unfortunately my requests for comments, how to proceed etc. have received
little response and I cannot generate discussion by myself :-).  I must
only gather that there is not much to discuss anymore.

If people have have specific issues -- please, always, bring them up!

-- 
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: Alain Durand <[email-masked]>
Date: Tue, 11 Jun 2002 23:58:06 -0700

> If people have have specific issues -- please, always, bring them up!

I still do not understand why this draft does not simply advocate using 
2 /128.

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Jun 2002 11:08:51 +0300 (EEST)

> I still do not understand why this draft does not simply advocate using 

I think we agree that the "first suggestion" would be to use /64 instead 
as required by addr-arch, right?

As for 2 /128's, I thought I had listed in the possible solutions section, 
but it seems it's only in the discussion part.  I'll add it to section two 
with /126:

--8<--
	2. Failing that, /126 does not have this problem, and it can be
	 used safely on a point-to-point link (e.g. using the 2nd and
	 the 3rd address for unicast).  This is analogous to using /30
	 for IPv4.  Naturally, not much would be lost if even a shorter
	 prefix was used, e.g. /112 or /120.

         Of course, 2 /128's could also be used.  This seems like an
	 elegant solution, but may be operationally more cumbersome with
	 some implementations (e.g. requiring to set a static route).

	 The author feels that if /64 cannot be used, /112, reserving
	 the last 16 bits for node identifiers, has probably the least
	 amount of drawbacks (also see section 3).
--8<--

Does this seem adequate?

As for the reasoning..

2 /128's work (internally) differently than e.g. /127, /126 or /64.  
It's often more complex to use them (e.g. with Juniper and Cisco you have
to use manually configured static routes), but sometimes not (e.g. KAME).  
To remember the focus, we're talking about a link between two routers. 

In addition, as 2 /128's work differently (the other end is reachable via
a static rather than connected route), it's something that will often face
problems (not so vigorously tested as it's not as generic code path,
implementation problems, ...).  For example, I noticed a bug in pim6sd RPF
validation using 2 /128's that didn't exist with "normal" prefix lengths.

So in conclusion, why not..?  But I'm not sure if it operationally (which
this draft was about) the simplest and the most robust course of action.

Other opinions on this?

---

From: Randy Bush <[email-masked]>
Date: Wed, 12 Jun 2002 08:04:15 -0700

> 	 some implementations (e.g. requiring to set a static route).

yuck!

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Jun 2002 20:12:39 +0300 (EEST)

> > 	 some implementations (e.g. requiring to set a static route).

As several people have expressed their dislike on this approach I propose 
either:

 a) remove the above section altogether (restore what it was),

 b) replace it with something like:

         In addition to using a different prefix length, one could use
         two /128's or avoid using global addresses altogether.  Further
         discussion on the benefits and drawbacks of different solutions
         is out of the scope, as it is not the goal of this memo to try
         to find "best" prefix length for everyone.

 c) suggest your own!