Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: ipv6

1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17)

 

 

nsp ipv6 RSS feed   Index | Next | Previous | View Threaded


jeroen at unfix

Aug 17, 2012, 2:57 AM

Post #1 of 25 (1206 views)
Permalink
1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17)

Fri 13T^W17'th surprise ssecial:

/128's.... and in non 2000::/3 space? Really!?

::/0 Default Route
+1::1/128 Unallocated prefix
+2::2/128 Unallocated prefix
64:ff9b::/96 Unallocated prefix
2000::/3 Default Route


grh.sixxs.net> show bgp 1::1
BGP routing table entry for 1::1/128
Paths: (21 available, best #21, table Default-IP-Routing-Table)
Not advertised to any peer
.... 8781 42298

aut-num: AS8781
as-name: QA-ISP
descr: Qatar Telecom (Qtel) Q.S.C.
org: ORG-QT1-RIPE

aut-num: AS42298
as-name: GCC-MPLS-peering
descr: Qatar Telecom (Qtel) Q.S.C.
descr: GCC MPLS peering

Not so strange that some GRH peers are peeking over 10.000 IPv6 prefixes
this way.

http://www.sixxs.net/tools/grh/status/

5497 good/required prefixes
Minimum of 578 prefixes (-4919)
Average of 9434 prefixes (+3937)
Maximum of 10155 prefixes (+4658)
191 peers, 81 not connected

Note that these are thus carrying 4658 unneeded routes... that means
almost 50% of the current IPv6 routing entries have no need to exist as
the covering prefixes would take care of them.

It's only 2012, lets see what this will look like in say 20 years, it
will likely be a big mess unless people clean up their acts (or buy much
much bigger routers and make smaller folks not be able to use BGP in a
standard way anymore)

Greets,
Jeroen


dr at cluenet

Aug 17, 2012, 3:41 AM

Post #2 of 25 (1179 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

Hi Jeroen,

On Fri, Aug 17, 2012 at 11:57:51AM +0200, Jeroen Massar wrote:
> /128's.... and in non 2000::/3 space? Really!?
>
> ::/0 Default Route
> +1::1/128 Unallocated prefix
> +2::2/128 Unallocated prefix
> 64:ff9b::/96 Unallocated prefix
> 2000::/3 Default Route

The problem with GRH is that people tend to send unfiltered IBGP to it
instead of a properly filtered EBGP stream. Thus GRH sees all kind of
more-specific/internal junk that noone else will see, resulting in
"false positives".

To me, this report will only have a real meaning when all GRH peers are
only sending an EBGP feed which they would also send a downstream BGP
customer. Unfortunately, that's largely not the case so I stopped
looking at the report a looong time ago.

Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr [at] cluenet -- dr [at] IRCne -- PGP: 0xA85C8AA0


jeroen at unfix

Aug 17, 2012, 3:57 AM

Post #3 of 25 (1178 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

On 2012-08-17 12:41, Daniel Roesen wrote:
> Hi Jeroen,
>
> On Fri, Aug 17, 2012 at 11:57:51AM +0200, Jeroen Massar wrote:
>> /128's.... and in non 2000::/3 space? Really!?
>>
>> ::/0 Default Route
>> +1::1/128 Unallocated prefix
>> +2::2/128 Unallocated prefix
>> 64:ff9b::/96 Unallocated prefix
>> 2000::/3 Default Route
>
> The problem with GRH is that people tend to send unfiltered IBGP to it
> instead of a properly filtered EBGP stream. Thus GRH sees all kind of
> more-specific/internal junk that noone else will see, resulting in
> "false positives".

While that is true, 1::1 and 2::2 should never exist anywhere, they are
outside of 2000::/3 and thus are not defined and thus should not be used
and definitely never ever be routed on the Internet. Same for that silly
64:ff9b::/96 prefix.

> To me, this report will only have a real meaning when all GRH peers are
> only sending an EBGP feed which they would also send a downstream BGP
> customer. Unfortunately, that's largely not the case so I stopped
> looking at the report a looong time ago.

That is true.

Maybe it is time to request peers to send prefixes in a certain way indeed.

We could also request people to send certain communities and instruct
GRH to ignore prefixes with certain communities for some reports.

Any proposals there?

Greets,
Jeroen


v6ops at stefan-neufeind

Aug 17, 2012, 4:02 AM

Post #4 of 25 (1180 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

On 08/17/2012 12:57 PM, Jeroen Massar wrote:
> On 2012-08-17 12:41, Daniel Roesen wrote:
>>
>> On Fri, Aug 17, 2012 at 11:57:51AM +0200, Jeroen Massar wrote:
>>> /128's.... and in non 2000::/3 space? Really!?
>>>
>>> ::/0 Default Route
>>> +1::1/128 Unallocated prefix
>>> +2::2/128 Unallocated prefix
>>> 64:ff9b::/96 Unallocated prefix
>>> 2000::/3 Default Route
>>
>> The problem with GRH is that people tend to send unfiltered IBGP to it
>> instead of a properly filtered EBGP stream. Thus GRH sees all kind of
>> more-specific/internal junk that noone else will see, resulting in
>> "false positives".
>
> While that is true, 1::1 and 2::2 should never exist anywhere, they are
> outside of 2000::/3 and thus are not defined and thus should not be used
> and definitely never ever be routed on the Internet. Same for that silly
> 64:ff9b::/96 prefix.
>
>> To me, this report will only have a real meaning when all GRH peers are
>> only sending an EBGP feed which they would also send a downstream BGP
>> customer. Unfortunately, that's largely not the case so I stopped
>> looking at the report a looong time ago.
>
> That is true.
>
> Maybe it is time to request peers to send prefixes in a certain way indeed.
>
> We could also request people to send certain communities and instruct
> GRH to ignore prefixes with certain communities for some reports.
>
> Any proposals there?

As a first step imho contact peers and ask them to only send routes also
meant for others/downstreams, as Daniel said.


Kind regards,
Stefan


md at Linux

Aug 17, 2012, 4:02 AM

Post #5 of 25 (1179 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

On Aug 17, Jeroen Massar <jeroen [at] unfix> wrote:

> Maybe it is time to request peers to send prefixes in a certain way indeed.
Agreed.

> We could also request people to send certain communities and instruct
> GRH to ignore prefixes with certain communities for some reports.
Why? If the routes are already properly tagged then they can easily
filter them on their side.

--
ciao,
Marco
Attachments: signature.asc (0.19 KB)


nick at foobar

Aug 17, 2012, 4:13 AM

Post #6 of 25 (1177 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

On 17/08/2012 10:57, Jeroen Massar wrote:
> It's only 2012, lets see what this will look like in say 20 years, it
> will likely be a big mess unless people clean up their acts (or buy much
> much bigger routers and make smaller folks not be able to use BGP in a
> standard way anymore)

Not really. We're trailing moore's law quite far behind, and the ratios
for total size:required prefixes for the ipv6 dfz look like the same sort
of scale as for ipv4.

Regarding the prefix leaks: le sigh. Don't people ever learn not to accept
arbitrary crap from customers? Prefix leaks require stupidity on two
parts, not just one.

Nick


jared at puck

Aug 17, 2012, 4:16 AM

Post #7 of 25 (1180 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

On Aug 17, 2012, at 7:13 AM, Nick Hilliard <nick [at] foobar> wrote:

> Regarding the prefix leaks: le sigh. Don't people ever learn not to accept
> arbitrary crap from customers? Prefix leaks require stupidity on two
> parts, not just one.

Sadly just one. It's not like the default Cisco policy is to block routes.

The path to a route leak is:

router bgp X
neighbor 2002::1:2:3:4 remote-as 5678

TCP can come up before the next line is typed/pasted, even if they did configure a policy.

- Jared


evyncke at cisco

Aug 17, 2012, 4:28 AM

Post #8 of 25 (1171 views)
Permalink
RE: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

> While that is true, 1::1 and 2::2 should never exist anywhere, they are
> outside of 2000::/3 and thus are not defined and thus should not be used
> and definitely never ever be routed on the Internet. Same for that silly
> 64:ff9b::/96 prefix.

Jeroen,
I am sure that you know that 64:ff9b::/96 is the 'official' prefix for NAT64 RFC 6052. It does not really change your conclusion anyway since this prefix should be kept within an AS

-éric


wmaton at ottix

Aug 17, 2012, 4:30 AM

Post #9 of 25 (1170 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

On Fri, 17 Aug 2012, Jared Mauch wrote:

>
> On Aug 17, 2012, at 7:13 AM, Nick Hilliard <nick [at] foobar> wrote:
>
>> Regarding the prefix leaks: le sigh. Don't people ever learn not to accept
>> arbitrary crap from customers? Prefix leaks require stupidity on two
>> parts, not just one.
>
> Sadly just one. It's not like the default Cisco policy is to block routes.
>
> The path to a route leak is:
>
> router bgp X
> neighbor 2002::1:2:3:4 remote-as 5678
>
> TCP can come up before the next line is typed/pasted, even if they did configure a policy.

If only the implementation were changed to force the user to invoke the
'activate' command there might be some hope that we can all be saved.

Yeah, yeah, I know.

wfms


lambert at psc

Aug 17, 2012, 4:35 AM

Post #10 of 25 (1174 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

On 17 Aug 2012, at 07:30, William F. Maton Sotomayor wrote:

> If only the implementation were changed to force the user to invoke the 'activate' command there might be some hope that we can all be saved.
>
> Yeah, yeah, I know.

s/invoke the 'activate' command/think/

Michael


nick at foobar

Aug 17, 2012, 4:43 AM

Post #11 of 25 (1169 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

On 17/08/2012 12:30, William F. Maton Sotomayor wrote:
> If only the implementation were changed to force the user to invoke the
> 'activate' command there might be some hope that we can all be saved.
>
> Yeah, yeah, I know.

or if the implementation were changed to...

- provide an atomic configuration commit system (e.g. xr, junos)

- put in an implicit deny for all bgp sessions without an explicit filter
on them

Nick


jeroen at unfix

Aug 17, 2012, 4:59 AM

Post #12 of 25 (1170 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

On 2012-08-17 13:28, Eric Vyncke (evyncke) wrote:
>
>> While that is true, 1::1 and 2::2 should never exist anywhere, they
>> are outside of 2000::/3 and thus are not defined and thus should
>> not be used and definitely never ever be routed on the Internet.
>> Same for that silly 64:ff9b::/96 prefix.
>
> Jeroen, I am sure that you know that 64:ff9b::/96 is the 'official'
> prefix for NAT64 RFC 6052.

No, I did not... and now I do, thanks.

It is oddly enough not registered in:
https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xml

> It does not really change your conclusion
> anyway since this prefix should be kept within an AS

The NAT64 prefix from just a few moments ago will pop up as such now in GRH.

Greets,
Jeroen

(off to find time to once and for all optimize GRH so that it is speedy
again...)


mwoliver at gmail

Aug 17, 2012, 5:08 AM

Post #13 of 25 (1170 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

On Fri, Aug 17, 2012 at 7:16 AM, Jared Mauch <jared [at] puck> wrote:
>
> Sadly just one. It's not like the default Cisco policy is to block routes.
>
> The path to a route leak is:
>
> router bgp X
> neighbor 2002::1:2:3:4 remote-as 5678
>
> TCP can come up before the next line is typed/pasted, even if they did
> configure a policy.

Of the varieties of IOS that I frequent, it's possible (and preferred
by me) to do the following:

router bgp X
neighbor 2002::1:2:3:4 remote-as 5678 shut
<policies, filters, etc.>
no neighbor 2002::1:2:3:4 shut

This provides the opportunity to define your necessary filters and
policies prior to the session startup.

--
Mike Oliver, KT2T


swmike at swm

Aug 17, 2012, 5:22 AM

Post #14 of 25 (1169 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

On Fri, 17 Aug 2012, Jared Mauch wrote:

> Sadly just one. It's not like the default Cisco policy is to block
> routes.

It's not the default IOS policy, but it is the default IOS XR policy.

--
Mikael Abrahamsson email: swmike [at] swm


dr at cluenet

Aug 17, 2012, 5:25 AM

Post #15 of 25 (1175 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

On Fri, Aug 17, 2012 at 12:13:17PM +0100, Nick Hilliard wrote:
> Regarding the prefix leaks: le sigh. Don't people ever learn not to accept
> arbitrary crap from customers? Prefix leaks require stupidity on two
> parts, not just one.

Those are not necessarily "leaks". There are a lot of GRH peers who
think they SHOULD actually send full unfiltered IBGP table and do it on
purpose. This is probably rooted in
http://www.sixxs.net/tools/grh/signup/
stating: "The peer is requested to send as much as possible though."

Perhaps this signup instructions should be polished up.

Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr [at] cluenet -- dr [at] IRCne -- PGP: 0xA85C8AA0


dr at cluenet

Aug 17, 2012, 5:27 AM

Post #16 of 25 (1171 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

On Fri, Aug 17, 2012 at 12:43:32PM +0100, Nick Hilliard wrote:
> - put in an implicit deny for all bgp sessions without an explicit filter
> on them

XR does that for EBGP:

"External BGP (eBGP) neighbors must have an inbound and an outbound
policy configured. If no policy is configured, no routes will be
accepted from the neighbor, nor will any routes be advertised to it.
This added security measure ensures that routes cannot accidentally be
accepted or advertised in the case where a configuration error results
in the intended policy being rejected.

This enforcement affects only eBGP neighbors (neighbors in a different
autonomous system than this networking device). For internal BGP (iBGP)
neighbors (neighbors in the same autonomous system), all routes will be
accepted or advertised if there is no policy."


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr [at] cluenet -- dr [at] IRCne -- PGP: 0xA85C8AA0


phil at philkern

Aug 17, 2012, 5:39 AM

Post #17 of 25 (1171 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

Daniel,

am Fri, Aug 17, 2012 at 02:25:08PM +0200 hast du folgendes geschrieben:
> Those are not necessarily "leaks". There are a lot of GRH peers who
> think they SHOULD actually send full unfiltered IBGP table and do it on
> purpose. This is probably rooted in
> http://www.sixxs.net/tools/grh/signup/
> stating: "The peer is requested to send as much as possible though."
>
> Perhaps this signup instructions should be polished up.

I don't think that matters much given that signup is basically not possible
anymore. ;-)

Kind regards
Philipp Kern
Attachments: signature.asc (0.19 KB)


sm at resistor

Aug 17, 2012, 8:52 AM

Post #18 of 25 (1169 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

Hi Jeroen,
At 04:59 17-08-2012, Jeroen Massar wrote:
>No, I did not... and now I do, thanks.
>
>It is oddly enough not registered in:
>https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xml

See Note 6 at
http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml

Regards,
-sm


jeroen at unfix

Aug 17, 2012, 8:59 AM

Post #19 of 25 (1169 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

On 2012-08-17 17:52, SM wrote:
> Hi Jeroen,
> At 04:59 17-08-2012, Jeroen Massar wrote:
>> No, I did not... and now I do, thanks.
>>
>> It is oddly enough not registered in:
>> https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xml
>>
>
> See Note 6 at
> http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml

While that is true, and what the RFC stated IANA had to do, would it not
be great if it actually was listed in the Special Registry as like,
well, ehmm, it is like, Special? :)

0100::/64 is noted in the latter as point 8, and listed in the Special one.

Also there is no links between these two lists, thus either you have the
one or the other, but you can't find either.

Greets,
Jeroen


sm at resistor

Aug 17, 2012, 9:34 AM

Post #20 of 25 (1168 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

Hi Jeroen,
At 08:59 17-08-2012, Jeroen Massar wrote:
>While that is true, and what the RFC stated IANA had to do, would it not
>be great if it actually was listed in the Special Registry as like,
>well, ehmm, it is like, Special? :)

Yes.

There was some discussion about this previously. I don't recall the outcome.

Regards,
-sm


johan at foreverfoss

Aug 17, 2012, 10:05 AM

Post #21 of 25 (1170 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

Philipp,

>
> I don't think that matters much given that signup is basically not possible
> anymore. ;-)

While that might have been a joke (I'm interpreting the smiley as
such), the criticism is not uncommon. I must ask you to view
http://www.sixxs.net/misc/requests/ for statistics on the matter,
clearly showing that the vast majority get approved, which has always
been the case. :-)

>
> Kind regards
> Philipp Kern

Best regards,
Johan Boger


wmaton at ottix

Aug 17, 2012, 10:43 AM

Post #22 of 25 (1169 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

On Fri, 17 Aug 2012, Michael H Lambert wrote:

> On 17 Aug 2012, at 07:30, William F. Maton Sotomayor wrote:
>
>> If only the implementation were changed to force the user to invoke the 'activate' command there might be some hope that we can all be saved.
>>
>> Yeah, yeah, I know.
>
> s/invoke the 'activate' command/think/

Ah. *Think*. Now that's in even less supply than clue. 8-|

>
> Michael
>
>

wfms


phil at philkern

Aug 17, 2012, 10:47 AM

Post #23 of 25 (1170 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

On Fri, Aug 17, 2012 at 07:05:45PM +0200, Johan Boger wrote:
> > I don't think that matters much given that signup is basically not possible
> > anymore. ;-)
> While that might have been a joke (I'm interpreting the smiley as
> such), the criticism is not uncommon. I must ask you to view
> http://www.sixxs.net/misc/requests/ for statistics on the matter,
> clearly showing that the vast majority get approved, which has always
> been the case. :-)

I'm talking about GRH, not tunnel requests. Never had any issue with the
latter.

Kind regards
Philipp Kern
Attachments: signature.asc (0.19 KB)


johan at foreverfoss

Aug 17, 2012, 4:00 PM

Post #24 of 25 (1172 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

> I'm talking about GRH, not tunnel requests. Never had any issue with the
> latter.

I stand corrected.

>
> Kind regards
> Philipp Kern

Best,

Johan Boger


fred at cisco

Aug 17, 2012, 4:50 PM

Post #25 of 25 (1168 views)
Permalink
Re: 1::1/128 + 2::2/128 - GRH Anomalies Delta (2012-08-17) [In reply to]

On Aug 17, 2012, at 4:28 AM, Eric Vyncke (evyncke) wrote:

> 64:ff9b::/96 is the 'official' prefix for NAT64 RFC 6052

"An" official one, and as an author of the document one I find ridiculous. Real deployments, such as 464XLAT, pretty much depend on it not being used.

nsp ipv6 RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.