/127 between routers?

[Jim Burwell]

On 1/5/2010 15:21, Mark Smith wrote:
> Hi Jim,
>
> On Tue, 05 Jan 2010 14:41:58 -0800
> Jim Burwell <jimb at jsbc.cc> wrote:
>
>   
>> On 1/5/2010 08:34, Roger Jørgensen wrote:
>>     
>>> On tir, januar 5, 2010 15:38, Andrew Alston wrote:
>>>   
>>>       
>>>> We use /127s all over the place on point to point links with no issues
>>>> (We went this route after considering what was said in the latest link
>>>> Janos posted below)
>>>>
>>>> Haven't really found any drawbacks with this yet
>>>>     
>>>>         
>>> Some year back I stopped using /127 when Linux refused to route my
>>> traffic. Had to add a static /128 for part of the /127 to get traffic
>>> flowing again. Later I changed to /126 and the problem disapeared. Wonder
>>> if I even had the same issue on some cisco routers to.
>>>
>>> Should be mention that it was all IPv6 in IPv4 tunnels so could be related
>>> to that to...
>>>
>>>
>>>   
>>>       
>> Makes sense to me.  It would seem to me that /126s were always the
>> logical equivalents of /30s in the IPv4 world for use on p-t-p links. 
>> /127s always seemed "wrong"  to me, since it uses the "magic" all-zeros
>> network identifier address as a host address.  :p 
>>
>> When I first started learning about IPv6, I wondered it the all-zeros or
>> all-ones host chunk of an IPv6 address held any special meaning as they
>> do in IPv4, and quickly figured out that all-ones doesn't, but all-zeros
>> still does.  A bit annoying in some ways since /127 would make a nice
>> XYZ::0,1 p-t-p interface address pairs, but oh well.  /126 it is.
>>
>> Having said that, the existence of that RFC and draft worries me about
>> using /126s at all, and one wonders if just sticking with /64s as seems
>> to be extolled as the best practice is the "right thing".  Others have
>> also made good points about /64 for convenience and consistancy in IPv6
>> addressing plans.  If it's easy to get say, an entire separate /48 to
>> use for /64 tunnel end points, then there's not much point in using
>> /126s, even if the "wastefulness" bugs me a bit.  :)
>>
>>     
> I think Michael Dillon from BT said something like when you live in a
> rainforest, you don't worry too much about how much water you use,
> which I think is a good analogy. Drop somebody into the rainforest,
> who's used to living in the desert, and I think it'd take them a little
> while to adjust to how much water they now can use ("use" is not
> equal to "waste"). That's the sort of struggle that I think people
> who've only used IPv4 will go through. 
>
>   
>> I've also wondered about the wisdom of perhaps using site-unique
>> addresses for things like tunnel end points, similar to the way I've
>> used RFC1918s for the same purpose in the IPv4 world.  Obviously using
>> non-global-routables wouldn't be good for all circumstances, but for the
>> typical tunnel or p-t-p link where the interface address might only be
>> used as a gateway for a local route entry, would it be a bad idea?
>>
>>     
> Doing so can break ICMP including PMTUD, traceroute, ping, both in IPv4
> and IPv6. The problem is that if the source IP address of the ICMP
> message is invalid over a domain it has to travel e.g. RFC1918
> addresses on the Internet, things like Reverse Path Forwarding checks
> can drop that traffic. If there is any chance of your routers seeing
> traffic from the Internet, now or in the future, it's better to use
> global i.e. non-private addressing on all of your links.
>
> I think you could get away with it if there was some configuration knob
> on the router to originate all ICMP traffic from specific public
> address e.g. a /32 (IPv4) or /128 (IPv6) on a loopback interface,
> however I haven't come across one yet, although I haven't looked all
> that hard.
>
>   
Yeh I wouldn't use this sort of thing if there was any chance that the
tunnel endpoint addresses would ever go outside of my routing domain. 
The addresses used would be fully routeable inside the enterprise, and I
wouldn't I'd use it anywhere where traffic to or from outside of my
routing domain would pass through it.  So PMTUD, etc, etc would continue
to work inside my enterprise since they'd be routeable.  Basically, I'd
use this, for example, in a leased WAN line scenario between sites which
had their own paths to the internet.  Traffic from the device itself
would never use those interfaces as source.

But it's pretty much moot because of the abundance of available IPv6
addresses.  But as another poster mentioned, old habits die hard when
you just came from the IPv4 "desert" into the IPv6 "rain forest".  :p 

Actually, I've been around long enough to remember when IPv4 addresses
seemed plentiful too, and we didn't do NAT, and had IPv4 publics on all
inside machines and just a normal statefull firewall fronting all that. 
Getting a class B or a bunch of Class C blocks wasn't difficult.  I've
seen IPv6 as a welcome return to those days w/o all the annoyances of
the RFC-1918/NAT world we live in now (such as address overlaps with
partners, aquired/merged companies, etc).  In some ways it'll be like
going back to the late 80s/early 90s.  :p

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5570 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100105/4b0d88a4/attachment.p7s>