On Tue, 11 Jun 2002, Alain Durand wrote:
> On Tuesday, June 11, 2002, at 11:39 PM, Pekka Savola wrote:
> >
> > 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.

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?

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


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

Reply via email to