nt
> Sent: Tuesday, August 31, 2010 6:01 PM
> To: Gert Doering
> Cc: v6...@ops.ietf.org; ipv6@ietf.org
> Subject: Re: ping-pong phenomenon with p2p links & /127 prefixes
>
> Hi, Gert,
>
> >> I think you miss my point: they might finally comply with the specs
> one
Hi, Gert,
>> I think you miss my point: they might finally comply with the specs one
>> day (if you ask or not, others might) and you will have forgotten about
>> this little subtle problem and upgrade your routers and voila your
>> network is broken.
>
> Cisco understands subnet-anycast, and dis
I don't agree with any of your points I'm afraid, and I don't think
they'd stand up to any thorough analysis (e.g. /128s verses /64s don't
have any significant impact on HD ratios when an ISP gets a _minimum_ of
a /32 or 4 billion /64s)
However, I don't think this conversation is making any progre
On Sat, Aug 28, 2010 at 11:26 PM, Mark Smith
wrote:
> On Sat, 28 Aug 2010 22:43:21 -0400
> Christopher Morrow wrote:
>
>> On Sat, Aug 28, 2010 at 7:34 PM, Mark Smith
>> wrote:
>>
>> > I think IPv6 "CIDR" i.e. longest match rule across the whole 128 bits is
>> > really only insurance against havi
On Sat, 28 Aug 2010 22:43:21 -0400
Christopher Morrow wrote:
> On Sat, Aug 28, 2010 at 7:34 PM, Mark Smith
> wrote:
>
> > I think IPv6 "CIDR" i.e. longest match rule across the whole 128 bits is
> > really only insurance against having to perform a whole of Internet
> > upgrade, similar to what
On Sat, Aug 28, 2010 at 7:34 PM, Mark Smith
wrote:
> I think IPv6 "CIDR" i.e. longest match rule across the whole 128 bits is
> really only insurance against having to perform a whole of Internet
> upgrade, similar to what had to happen when CIDR was introduced, should
folk are already holding (
Hi Bert,
On Wed, 25 Aug 2010 14:44:31 -0500
"Manfredi, Albert E" wrote:
> Mark Smith:
>
> > Possibly it will be surprising to a number of people on this list, but
> > some of the ideas in IPv6 are over 30 years old, such as single, fixed
> > size network and node portions, and using link layer
Mark Smith:
> Possibly it will be surprising to a number of people on this list, but
> some of the ideas in IPv6 are over 30 years old, such as single, fixed
> size network and node portions, and using link layer
> addresses as layer
> 3 node addresses -
>
> "Address Mappings", Jonathan B. Poste
On Wed, 25 Aug 2010 00:57:12 -0400
Christopher Morrow wrote:
> On Mon, Aug 23, 2010 at 5:23 PM, Jared Mauch wrote:
> > Operationally the vendors may be violating some RFC, so lets publish what is
> > relevant and working today so we can all move on? We can deal with
> > any additional updates a
On Wed, 25 Aug 2010 00:55:34 -0400
Christopher Morrow wrote:
> On Mon, Aug 23, 2010 at 5:38 PM, Mark Smith
> wrote:
> > On Mon, 23 Aug 2010 17:23:09 -0400
> > Jared Mauch wrote:
> >
> >>
> >> On Aug 23, 2010, at 4:49 PM, Mark Smith wrote:
> >>
> >> > On Mon, 23 Aug 2010 09:55:48 -0400
> >> > Ja
On Mon, 23 Aug 2010 17:19:03 -0500
"Manfredi, Albert E" wrote:
> Mark Smith:
>
> > Well, GPS was only one of the examples I used, and I was envisioning
> > one that is built into the dash. To continue with the
> > analogy, how many
> > people would buy and install after-market electric windows,
On Mon, Aug 23, 2010 at 5:23 PM, Jared Mauch wrote:
> Operationally the vendors may be violating some RFC, so lets publish what is
> relevant and working today so we can all move on? We can deal with
> any additional updates and items with "how IPv6" works elsewhere or in a
> new document so we c
On Mon, Aug 23, 2010 at 5:38 PM, Mark Smith
wrote:
> On Mon, 23 Aug 2010 17:23:09 -0400
> Jared Mauch wrote:
>
>>
>> On Aug 23, 2010, at 4:49 PM, Mark Smith wrote:
>>
>> > On Mon, 23 Aug 2010 09:55:48 -0400
>> > Jared Mauch wrote:
>> >
>> >>
>> >> On Aug 23, 2010, at 9:17 AM, Mark Smith wrote:
>
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
sth...@nethelp.no
Sent: Monday, August 23, 2010 5:58 PM
To: i...@69706e6720323030352d30312d31340a.nosense.org
Cc: v6...@ops.ietf.org; ipv6@ietf.org
Subject: Re: ping-pong phenomenon with p2p links
On Aug 23, 2010, at 2:53 PM, Manfredi, Albert E wrote:
> Jared Mauch:
>
>> The biggest feedback I hear from people about IPv6 (besides the extra
>> bits for addressses) is "Security", but they generally don't know what
>> that is outside marketing speak.
>
> +1, in spades. Nor do these folk see
Mark Smith:
> Well, GPS was only one of the examples I used, and I was envisioning
> one that is built into the dash. To continue with the
> analogy, how many
> people would buy and install after-market electric windows, anti-lock
> brakes, electronic fuel injection etc.?
Analogies work both way
On Mon, 23 Aug 2010 17:19:26 -0400
Jared Mauch wrote:
>
> On Aug 23, 2010, at 5:11 PM, Mark Smith wrote:
>
> > On Mon, 23 Aug 2010 17:24:00 +0200 (CEST)
> > sth...@nethelp.no wrote:
> >
> >>> And all you'll end up with is IPv4 with bigger addresses. You really
> >>> should catch up with the us
> I don't claim to represent all views on IPv6. I *do* claim that a view
> that "more addresses" is the only justification for IPv6 is reasonably
> widespread.
you don't want mandatory ipsec, longer battery life, ...? :)
96 more bits, no magic -- gaurab
the problems existing operators (who just
> > > And all you'll end up with is IPv4 with bigger addresses. You really
> > > should catch up with the useful features of protocols that were
> > > designed in the late 80s / early 90s, like IPX, Appletalk, DECNet and
> > > CLNS.
> >
> > For me "more addresses" is the *only* justification for I
Jared Mauch:
> The biggest feedback I hear from people about IPv6 (besides the extra
> bits for addressses) is "Security", but they generally don't know what
> that is outside marketing speak.
+1, in spades. Nor do these folk seem to appreciate that it's not the network
that bears the greatest b
On 8/23/10 5:11 AM, sth...@nethelp.no wrote:
>> These mechanisms are applicable to any type of link, would preserve the
>> simplicity of universal 64 bit IIDs and the other benefits of them e.g.
>> CGAs, as well as avoiding the ping-pong problem.
>
> IMHO, the "universality" of 64 bit IIDs went do
On Mon, 23 Aug 2010 17:23:09 -0400
Jared Mauch wrote:
>
> On Aug 23, 2010, at 4:49 PM, Mark Smith wrote:
>
> > On Mon, 23 Aug 2010 09:55:48 -0400
> > Jared Mauch wrote:
> >
> >>
> >> On Aug 23, 2010, at 9:17 AM, Mark Smith wrote:
> >>
> >>> On Mon, 23 Aug 2010 14:11:04 +0200 (CEST)
> >>> st
On Aug 23, 2010, at 4:49 PM, Mark Smith wrote:
> On Mon, 23 Aug 2010 09:55:48 -0400
> Jared Mauch wrote:
>
>>
>> On Aug 23, 2010, at 9:17 AM, Mark Smith wrote:
>>
>>> On Mon, 23 Aug 2010 14:11:04 +0200 (CEST)
>>> sth...@nethelp.no wrote:
>>>
> These mechanisms are applicable to any type
On Aug 23, 2010, at 5:11 PM, Mark Smith wrote:
> On Mon, 23 Aug 2010 17:24:00 +0200 (CEST)
> sth...@nethelp.no wrote:
>
>>> And all you'll end up with is IPv4 with bigger addresses. You really
>>> should catch up with the useful features of protocols that were
>>> designed in the late 80s / earl
On Mon, 23 Aug 2010 17:24:00 +0200 (CEST)
sth...@nethelp.no wrote:
> > And all you'll end up with is IPv4 with bigger addresses. You really
> > should catch up with the useful features of protocols that were
> > designed in the late 80s / early 90s, like IPX, Appletalk, DECNet and
> > CLNS.
>
> F
On Mon, 23 Aug 2010 09:55:48 -0400
Jared Mauch wrote:
>
> On Aug 23, 2010, at 9:17 AM, Mark Smith wrote:
>
> > On Mon, 23 Aug 2010 14:11:04 +0200 (CEST)
> > sth...@nethelp.no wrote:
> >
> >>> These mechanisms are applicable to any type of link, would preserve the
> >>> simplicity of universal
On Aug 23, 2010, at 1:15 PM, Joel Jaeggli wrote:
> On 8/23/10 5:11 AM, sth...@nethelp.no wrote:
>>> These mechanisms are applicable to any type of link, would preserve the
>>> simplicity of universal 64 bit IIDs and the other benefits of them e.g.
>>> CGAs, as well as avoiding the ping-pong probl
+1
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
sth...@nethelp.no
Sent: Tuesday, August 24, 2010 12:24 AM
To: i...@69706e6720323030352d30312d31340a.nosense.org
Cc: v6...@ops.ietf.org; ipv6@ietf.org
Subject: Re: ping-pong phenomenon with p2p
kbone operation
in practice.
Miya
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Mark Smith
Sent: Monday, August 23, 2010 10:47 PM
To: Randy Bush
Cc: v6...@ops.ietf.org; ipv6@ietf.org
Subject: Re: ping-pong phenomenon with p2p links & /127 prefixes
> And all you'll end up with is IPv4 with bigger addresses. You really
> should catch up with the useful features of protocols that were
> designed in the late 80s / early 90s, like IPX, Appletalk, DECNet and
> CLNS.
For me "more addresses" is the *only* justification for IPv6. All the
other "usef
On Aug 23, 2010, at 9:17 AM, Mark Smith wrote:
> On Mon, 23 Aug 2010 14:11:04 +0200 (CEST)
> sth...@nethelp.no wrote:
>
>>> These mechanisms are applicable to any type of link, would preserve the
>>> simplicity of universal 64 bit IIDs and the other benefits of them e.g.
>>> CGAs, as well as avo
On Mon, 23 Aug 2010 22:27:27 +0900
Randy Bush wrote:
> >> The IPv6 standards community can of course continue to pretend a
> >> belief in universal 64 bit IIDs - thus ensuring that they are out of
> >> touch with IPv6 reality...
> >
> > Maybe that's your reality, but it isn't everybody's.
>
> a
>> The IPv6 standards community can of course continue to pretend a
>> belief in universal 64 bit IIDs - thus ensuring that they are out of
>> touch with IPv6 reality...
>
> Maybe that's your reality, but it isn't everybody's.
as you demonstrate so clearly
but those of us who are operators and a
On Mon, 23 Aug 2010 14:11:04 +0200 (CEST)
sth...@nethelp.no wrote:
> > These mechanisms are applicable to any type of link, would preserve the
> > simplicity of universal 64 bit IIDs and the other benefits of them e.g.
> > CGAs, as well as avoiding the ping-pong problem.
>
> IMHO, the "universali
> These mechanisms are applicable to any type of link, would preserve the
> simplicity of universal 64 bit IIDs and the other benefits of them e.g.
> CGAs, as well as avoiding the ping-pong problem.
IMHO, the "universality" of 64 bit IIDs went down the drain the moment
router vendors allowed longe
On Mon, 23 Aug 2010 09:06:50 +0900
Randy Bush wrote:
> > If the /127 draft is a rebuttal of RFC3627
>
> and if it isn't? maybe it's just a bug report on one bit?
>
Well, firstly, this is the text in the /127 draft which seems to
suggest to me it is:
"This document provides rationale for usin
> If the /127 draft is a rebuttal of RFC3627
and if it isn't? maybe it's just a bug report on one bit?
> Other examples - there are probably more - of things I think that should
> be discussed, beyond what is in RFC3627 -
where is that darned immersion heater?
randy
---
On Sun, 22 Aug 2010 12:30:25 -0400
Christopher Morrow wrote:
> On Sun, Aug 22, 2010 at 12:09 PM, Miya Kohno wrote:
> > Hi Mark,
> >
> >> > *Except /127*, we support rfc3627 and the appendix B.2 of rfc5375.
> > They
> >> > have properly addressed the implication for using longer prefix than
> >>
On Sun, Aug 22, 2010 at 12:09 PM, Miya Kohno wrote:
> Hi Mark,
>
>> > *Except /127*, we support rfc3627 and the appendix B.2 of rfc5375.
> They
>> > have properly addressed the implication for using longer prefix than
>> > /64.
>> >
>>
>> So where is there reference to Appendix B.2 of RFC5375 in t
Hi Mark,
> > *Except /127*, we support rfc3627 and the appendix B.2 of rfc5375.
They
> > have properly addressed the implication for using longer prefix than
> > /64.
> >
>
> So where is there reference to Appendix B.2 of RFC5375 in the /127
> draft? The draft does not mention anything about the
Hi Miya,
On Thu, 19 Aug 2010 20:56:57 +0800
Miya Kohno wrote:
> > > then you will join us supporting the /127 document and it won't be a
> > > problem, will it.
> > >
> >
> > Why won't you and the other authors do a proper job with it then? It
> > doesn't address all the implications that arise
> > then you will join us supporting the /127 document and it won't be a
> > problem, will it.
> >
>
> Why won't you and the other authors do a proper job with it then? It
> doesn't address all the implications that arise. It should, point by
> point address, all the issues in RFC3627. It should a
dear stephen daedalus,
> The whole point of IPv6 is to make addresses and prefixes plentiful.
> If global addresses facilitate the management of peering, why exactly
> would we not provide sufficient allocations to the network managers?
who has said they are not provided?
> Do we really believe
>> So, to sum up: yes, we know that the IPv6 link local addresses exist
>> on our routers, no we don't normally "deal" with these addresses in
>> any way.
>
> and hope we don't have to, because they are not reachable, not uniqie, have
> no mapping to the way we think of and name the interfaces,
>>> Thus, do ask Cisco and Juniper and other vendors where this now
>>> 'works' if this intentional, or if they might finally comply to the
>>> IPv6 specifications one day, as then you might better watch out for
>>> this as it will break your network. For the vendors that have it,
>>> it might mayb
Ole Troan wrote:
>> Thus, do ask Cisco and Juniper and other vendors where this now
>> 'works' if this intentional, or if they might finally comply to the
>> IPv6 specifications one day, as then you might better watch out for
>> this as it will break your network. For the vendors that have it,
>>
On 17/08/2010, at 7:11 AM, sth...@nethelp.no wrote:
>>> Even if I did know the other side's global address, monitoring pings
>>> cannot be sent to fe80::2. We'll have to ping c001:cafe::2 and
>>> manually link that status with fe80::2 peering session on the NMS.
>>> I would hate to do that with hu
> So, to sum up: yes, we know that the IPv6 link local addresses exist
> on our routers, no we don't normally "deal" with these addresses in
> any way.
and hope we don't have to, because they are not reachable, not uniqie,
have no mapping to the way we think of and name the interfaces, ...
and ye
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ole-san
Ole Troan wrote:
> Seiichi-san,
>
>>> BGP peerings and what not could use link-local addresses. e.g:
>>>
>>> router A -- router B
>>> fe80::1fe80::2
>>> dead:beef::1/128 c001:cafe::2/128
>> if
>>
> > Even if I did know the other side's global address, monitoring pings
> > cannot be sent to fe80::2. We'll have to ping c001:cafe::2 and
> > manually link that status with fe80::2 peering session on the NMS.
> > I would hate to do that with hundreds of sessions running inside my network.
> > Tha
Seiichi-san,
>> BGP peerings and what not could use link-local addresses. e.g:
>>
>> router A -- router B
>> fe80::1fe80::2
>> dead:beef::1/128 c001:cafe::2/128
>
> if
> I get a BGP neighbor down message with fe80::2
> then
> what address do I ping, t
> link-local addresses have a very-limited use (and in some cases no use
> at all in the backbone that we operate).
i fear we are talking to people who don't go past the head end. cisco
is big, and folk can get tunnel vision.
randy
On Aug 16, 2010, at 8:33 PM, Ole Troan wrote:
>>> please ping my router, it's interface address is:
>>> fe80::20e:cff:fe5c:b001/64
>>>
>>> my monitoring system can't ping this to ensure liveness of the
>>> interface either :(
>> but they can ping whatever global /128 you
On Mon, Aug 16, 2010 at 8:33 PM, Ole Troan wrote:
>>> please ping my router, it's interface address is:
>>> fe80::20e:cff:fe5c:b001/64
>>>
>>> my monitoring system can't ping this to ensure liveness of the
>>> interface either :(
>> but they can ping whatever global /128 y
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ole-san
Ole Troan wrote:
>>> please ping my router, it's interface address is:
>>> fe80::20e:cff:fe5c:b001/64
>>>
>>> my monitoring system can't ping this to ensure liveness of the
>>> interface either :(
>> but they can pi
>> please ping my router, it's interface address is:
>> fe80::20e:cff:fe5c:b001/64
>>
>> my monitoring system can't ping this to ensure liveness of the
>> interface either :(
> but they can ping whatever global /128 you put on that interface, so why
> doesn't that sol
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jared Mauch wrote:
>
> Jared Mauch
>
> On Aug 16, 2010, at 5:01 PM, Ole Troan wrote:
>
> please ping my router, it's interface address is:
> fe80::20e:cff:fe5c:b001/64
>
> my monitoring system can't ping this to ensure liveness of
August 16, 2010 4:29 AM
> To: Jeroen Massar
> Cc: v6...@ops.ietf.org; ipv6@ietf.org
> Subject: Re: ping-pong phenomenon with p2p links & /127 prefixes
>
[...]
>
> But I'm still interested in knowing what's the downside of the fix in
> RFC 4443 that I cited in
Jared Mauch
On Aug 16, 2010, at 5:01 PM, Ole Troan wrote:
please ping my router, it's interface address is:
fe80::20e:cff:fe5c:b001/64
my monitoring system can't ping this to ensure liveness of the
interface either :(
>>>
>>> but they can ping whatever global /128 y
>> but they can ping whatever global /128 you put on that interface, so
>> why doesn't that solve the problems?
> Because you are then using one set of addresses for protool peerings
> and another one for global ping - thus making life more complicated
> for the operator.
and is sure to have reall
On Mon, 16 Aug 2010 11:48:41 +0200
Ole Troan wrote:
> Jeroen,
>
> >>> Unless you configure two /128's pointing to the remote side, which will
> >>> then thus not be 'on-link for neighbor discovery, the little thing
> >>> called the subnet anycast address will make sure that a /127 ptp simply
> >
>>> please ping my router, it's interface address is: fe80::20e:cff:fe5c:b001/64
>>>
>>> my monitoring system can't ping this to ensure liveness of the
>>> interface either :(
>>
>> but they can ping whatever global /128 you put on that interface, so why
>> doesn't that solve the problems?
>
>
> > please ping my router, it's interface address is: fe80::20e:cff:fe5c:b001/64
> >
> > my monitoring system can't ping this to ensure liveness of the
> > interface either :(
>
> but they can ping whatever global /128 you put on that interface, so why
> doesn't that solve the problems?
Because
one could equally just make a convention to use link-locals with fe80::1
and fe80::2
and /128s on each side if one needed global addresses for sources to
traceroute etc.
>>>
>>> no, ping/monitoring/data-collection fails in this case. (or needs to
>>> be overhauled to collect/
On Mon, Aug 16, 2010 at 2:49 PM, Ole Troan wrote:
>
> On Aug 16, 2010, at 20:34 , Christopher Morrow wrote:
>
>> On Mon, Aug 16, 2010 at 7:54 AM, Ole Troan wrote:
>>
>>> one could equally just make a convention to use link-locals with fe80::1
>>> and fe80::2
>>> and /128s on each side if one nee
Jared,
> Please explain how ll would solve the problem first. Maybe the bcp38+1918
> thread on nanog on recent days would be instructive.
which problem? there are several.
with regards to the NANOG reference, I don't quite see the similarity. I
haven't seen any implementation sourcing packets
Please explain how ll would solve the problem first. Maybe the bcp38+1918
thread on nanog on recent days would be instructive.
Jared Mauch
On Aug 16, 2010, at 2:49 PM, Ole Troan wrote:
>
> On Aug 16, 2010, at 20:34 , Christopher Morrow wrote:
>
>> On Mon, Aug 16, 2010 at 7:54 AM, Ole Troan
On Aug 16, 2010, at 20:34 , Christopher Morrow wrote:
> On Mon, Aug 16, 2010 at 7:54 AM, Ole Troan wrote:
>
>> one could equally just make a convention to use link-locals with fe80::1 and
>> fe80::2
>> and /128s on each side if one needed global addresses for sources to
>> traceroute etc.
>
On Mon, Aug 16, 2010 at 7:54 AM, Ole Troan wrote:
> one could equally just make a convention to use link-locals with fe80::1 and
> fe80::2
> and /128s on each side if one needed global addresses for sources to
> traceroute etc.
no, ping/monitoring/data-collection fails in this case. (or needs
On man, august 16, 2010 11:46, Randy Bush wrote:
>>> I have no plans to ask Cisco and Juniper about this. I want /127 to
>>> continue working, and couldn't care less about subnet anycast for my
>>> core routers.
>>
>> I think you miss my point: they might finally comply with the specs one
>> day (i
Hi,
On Mon, Aug 16, 2010 at 11:43:54AM +0200, Jeroen Massar wrote:
> I think you miss my point: they might finally comply with the specs one
> day (if you ask or not, others might) and you will have forgotten about
> this little subtle problem and upgrade your routers and voila your
> network is b
On Mon, 16 Aug 2010 18:46:18 +0900
Randy Bush wrote:
> >> I have no plans to ask Cisco and Juniper about this. I want /127 to
> >> continue working, and couldn't care less about subnet anycast for my
> >> core routers.
> >
> > I think you miss my point: they might finally comply with the specs o
>>> P.S.: This fix doesn't prevent the use of /127s (it's orthogonal),
>>
>> Unless you configure two /128's pointing to the remote side, which will
>> then thus not be 'on-link for neighbor discovery, the little thing
>> called the subnet anycast address will make sure that a /127 ptp simply
>> d
Jeroen Massar wrote:
>> P.S.: This fix doesn't prevent the use of /127s (it's orthogonal),
>
> Unless you configure two /128's pointing to the remote side, which will
> then thus not be 'on-link for neighbor discovery, the little thing
> called the subnet anycast address will make sure that a /12
>> asking the question another way. is it still a good idea, or was it
>> ever?
> Currently I don't see the use. The only use seems to be an extra
> annoying slide when one is explaining all the 'good stuff about IPv6'
is anyone using ipv6's special anycast at all?
i see use of v4-style anycast i
[two replies in once before I truly fill up every one's mailboxes ;) ]
On 2010-08-16 11:46, Randy Bush wrote:
>>> I have no plans to ask Cisco and Juniper about this. I want /127 to
>>> continue working, and couldn't care less about subnet anycast for my
>>> core routers.
>>
>> I think you miss my
Jeroen,
>>> Unless you configure two /128's pointing to the remote side, which will
>>> then thus not be 'on-link for neighbor discovery, the little thing
>>> called the subnet anycast address will make sure that a /127 ptp simply
>>> does not work, unless you have a platform which disables the su
>> I have no plans to ask Cisco and Juniper about this. I want /127 to
>> continue working, and couldn't care less about subnet anycast for my
>> core routers.
>
> I think you miss my point: they might finally comply with the specs one
> day (if you ask or not, others might) and you will have forg
On 2010-08-16 11:41, sth...@nethelp.no wrote:
>> Thus, do ask Cisco and Juniper and other vendors where this now 'works'
>> if this intentional, or if they might finally comply to the IPv6
>> specifications one day, as then you might better watch out for this as
>> it will break your network. For t
> Thus, do ask Cisco and Juniper and other vendors where this now 'works'
> if this intentional, or if they might finally comply to the IPv6
> specifications one day, as then you might better watch out for this as
> it will break your network. For the vendors that have it, it might maybe
> be an id
On 2010-08-16 11:12, sth...@nethelp.no wrote:
>> Unless you configure two /128's pointing to the remote side, which will
>> then thus not be 'on-link for neighbor discovery, the little thing
>> called the subnet anycast address will make sure that a /127 ptp simply
>> does not work, unless you have
> Unless you configure two /128's pointing to the remote side, which will
> then thus not be 'on-link for neighbor discovery, the little thing
> called the subnet anycast address will make sure that a /127 ptp simply
> does not work, unless you have a platform which disables the subnet
> anycast ad
On 2010-08-16 10:08, Fernando Gont wrote:
[..]
> P.S.: This fix doesn't prevent the use of /127s (it's orthogonal),
Unless you configure two /128's pointing to the remote side, which will
then thus not be 'on-link for neighbor discovery, the little thing
called the subnet anycast address will make
83 matches
Mail list logo
