[ncc-announce] 128.0.0.0/16 configured as martians in some routers

Dear Colleagues,

The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline that this /16 should no longer be reserved as specialised address space.

All allocations that were already issued have been exchanged and for now we will hold this space in quarantine.

We urge everyone to change the default behaviour of their Juniper routers:

set routing-options martians 128.0.0.0/16 orlonger allow
set routing-options martians 191.255.0.0/16 orlonger allow
set routing-options martians 223.255.255.0/24 exact allow

128.0.0.0/16 has been added to the RIPE NCC's Debogonising Project:

http://www.ris.ripe.net/debogon/

To facilitate testing, the following prefixes are being announced:

prefix pinagble address

128.0.0.0/16 128.0.0.1
128.0.8.0/21 128.0.8.1
128.0.24.0/24 128.0.24.1

Best regards,

Alex Le Heux
Policy Implementation Co-ordinator
RIPE NCC

Dear Colleagues,

The correct prefix and pingable address list for the Debogonising Project is:

prefix pinagble address

128.0.0.0/21 128.0.0.1
128.0.24.0/24 128.0.24.1

Our apologies for the oversight.

Best regards,

Alex Le Heux
Policy Implementation Co-ordinator
RIPE NCC

Once upon a time, Alex Le Heux <alexlh@ripe.net> said:

Dear Colleagues,

The correct prefix and pingable address list for the Debogonising Project is:

prefix pinagble address

128.0.0.0/21 128.0.0.1
128.0.24.0/24 128.0.24.1

Our apologies for the oversight.

Are these prefixes being announced widely? I don't see anything for
128.0.0.0/16 from my upstreams, nor at many public looking glasses.

We do have it from Level3:

C:\Documents and Settings\TAYEB>tracert 128.0.0.1

D�termination de l'itin�raire vers 128.0.0.1 avec un maximum de 30 sauts.

  1 1 ms 3 ms 3 ms 172.28.0.1
  2 3 ms 3 ms 3 ms 10.16.0.1
  3 13 ms 15 ms 16 ms 41.200.0.1
  4 32 ms 12 ms 16 ms 172.17.2.25
  5 15 ms 16 ms 16 ms 213.140.58.10
  6 35 ms 40 ms 34 ms 212.73.253.65
  7 39 ms 39 ms 39 ms ae-5-6.bar2.Marseille1.Level3.net [4.69.151.13]

  8 52 ms 76 ms 54 ms ae-15-15.ebr1.Frankfurt1.Level3.net [4.69.143.24
6]
  9 56 ms 56 ms 55 ms ae-81-81.csw3.Frankfurt1.Level3.net [4.69.140.10
]
10 55 ms 55 ms 57 ms ae-82-82.ebr2.Frankfurt1.Level3.net [4.69.140.25
]
11 58 ms 67 ms 62 ms ae-46-46.ebr1.Dusseldorf1.Level3.net [4.69.143.1
69]
12 55 ms 55 ms 56 ms ae-24-24.ebr2.Dusseldorf1.Level3.net [4.69.143.1
94]
13 172 ms 58 ms 57 ms ae-48-48.ebr1.Amsterdam1.Level3.net [4.69.143.20
9]
14 58 ms 58 ms 67 ms ae-59-114.csw1.Amsterdam1.Level3.net [4.69.153.1
98]
15 60 ms 62 ms 62 ms ae-19-51.sar1.Amsterdam1.Level3.net [4.69.139.14
6]
16 * 56 ms 58 ms 128.0.0.1

Itin�raire d�termin�.

C:\Documents and Settings\TAYEB>

I'm see them from NTT.

-Kyle

Once I updated junos 10.4R7.5 martian list, I saw them both from level3 and qwest, but not from Sprint.

Jack

Once upon a time, Jack Bates <jbates@brightok.net> said:

Here is my little table for 128.0.0.0/21 based on our upstreams:

AS7922: Yes
AS174: No
AS2914: Yes
AS3257: Yes
AS2914: Yes
AS2828: No
AS209: Yes

John @ AS11404

* Alex Le Heux:

The RIPE NCC is aware that 128.0.0.0/16 is configured as a martian by
default in (some) Juniper OS, even though RFC 5735 and RFC3330 outline
that this /16 should no longer be reserved as specialised address
space.

Would someone please clarify the impact? Will it result in a blackhole,
or will the entire announcement be suppressed? I suspect the latter,
given what we see and what Chris Adams has reported.

Would someone please clarify the impact? Will it result in a blackhole,
or will the entire announcement be suppressed? I suspect the latter,
given what we see and what Chris Adams has reported.

This is what we see on Cisco IOS and IOS XR boxes:

lab#sh ip bgp 128.0.0.0
BGP routing table entry for 128.0.0.0/21, version 260804693
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     2
  3491 3257 1103 12654
    61.11.xxx.yy (metric 34400) from 61.11.xxx.zz (61.11.xxx.zz)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: 24218:1
      Originator: 61.11.xxx.yy, Cluster list: 0.0.0.2
  3491 3257 1103 12654
    61.11.xxx.yy (metric 34400) from 61.11.xxx.ww (61.11.xxx.ww)
      Origin IGP, metric 0, localpref 100, valid, internal
      Community: 24218:1
      Originator: 61.11.xxx.yy, Cluster list: 0.0.0.2
lab#

RP/0/RSP0/CPU0:lab#sh route 128.0.0.0
Tue Dec 6 17:09:13.439 MYT

Routing entry for 128.0.0.0/21
  Known via "bgp 24218", distance 200, metric 0
  Tag 3491, type internal
  Installed Dec 4 20:00:33.089 for 1d21h
  Routing Descriptor Blocks
    61.11.xxx.yy, from 61.11.yyy.zz
      Route metric is 0
  No advertising protos.
RP/0/RSP0/CPU0:lab#

This is what we see on an unfixed Juniper:

tinka@lab# run show route 128.0.0.0

inet.0: 384214 destinations, 768288 routes (384212 active, 0 holddown, 4 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[Static/5] 20w2d 13:21:14
                      Discard

[edit]
tinka@lab#

tinka@lab# run show route 128.0.0.0/21

inet.0: 384218 destinations, 768296 routes (384216 active, 0 holddown, 4 hidden)
Restart Complete

[edit]
tinka@lab#

tinka@edge-gw-1-sin-pip.sg# run show route 128.0.0.0/21 hidden

inet.0: 384224 destinations, 768308 routes (384222 active, 0 holddown, 4 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

128.0.0.0/21 [BGP/170] 1d 21:17:54, MED 0, localpref 100, from 61.11.xxx.ww
                      AS path: 3491 3257 1103 12654 I
                    > to 124.158.xxx.uu via ge-0/0/0.0, Push 16052
                      to 124.158.xxx.vv via ge-0/0/0.0, Push 16017
                      to 124.158.xxx.ww via ge-0/1/0.0, Push 16052
                      to 124.158.xxx.xx via ge-0/1/0.0, Push 16017
                    [BGP/170] 1d 21:17:54, MED 0, localpref 100, from 61.11.xxx.zz
                      AS path: 3491 3257 1103 12654 I
                    > to 124.158.xxx.uu via ge-0/0/0.0, Push 16052
                      to 124.158.xxx.vv via ge-0/0/0.0, Push 16017
                      to 124.158.xxx.ww via ge-0/1/0.0, Push 16052
                      to 124.158.xxx.xx via ge-0/1/0.0, Push 16017

[edit]
tinka@edge-gw-1-sin-pip.sg#

tinka@lab# run show route 128.0.0.0/21 hidden extensive | match State
                State: <Hidden Martian Int Ext>
                State: <Hidden Martian Int Ext>

[edit]
tinka@lab#

tinka@lab# run show interfaces terse
<snip>
...

fxp1 up up
fxp1.0 up up inet 10.0.0.1/8
                                            10.0.0.4/8
                                            128.0.0.1/2
                                            128.0.0.4/2
                                   inet6 fe80::200:ff:fe00:4/64
                                            fec0::a:0:0:4/64
                                   tnp 0x4

<snip>
...

[edit]
tinka@lab#

This is what we see on a Cisco router which lives behind
an unfixed Juniper router that is peering externally:

lab#sh ip bgp 128.0.0.0
% Network not in table
lab#

So our deduction - if a Juniper router is in the data path,
it will blackhole traffic destined to this address.

If a Juniper is in the control plane path, it will
filter this prefix and not send it to the rest of the
network.

Either way, you're screwed :-).

Cheers,

Mark.

Hi Alex,

In Dayton, Ohio, US, we are not seeing any 128... routes from TWTC (AS 4323).

In St. Louis, Ohio, US, we are seeing the 128.0.0.0/21 via Level 3 (AS 3356).

David Swafford,
Sr. Network Engineer, CareSource

http://www.juniper.net/techpubs/en_US/junos10.2/topics/usage-guidelines/routing-configuring-martian-addresses.html

For those who might not be aware, an OS-level fix has been
integrated into the following Junos releases:

  - 10.0R5
  - 10.4R8
  - 10.4R9
  - 11.1R7
  - 11.2R4
  - 11.3R3
  - 11.4R1
  - 11.4R2
  - 12.1R1

Cheers,

Mark.

If anyone on Cogent is lurking, we are not receiving the announcements yet
in our BGP table.

Double checked on the looking glass, and it looks company wide.
http://www.cogentco.com/en/network/looking-glass

The space is seen through Level3...

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300
F: 610-429-3222

we are also receyving it through level3.