RE: ipv6 bogon / martian filter - simple

[George, Wes E IV [NTK]]

This would be another alternative:
http://www.space.net/~gert/RIPE/ipv6-filters.html

Slightly more than 1 line, but the loose case would nuke a few more things than 
just filtering on 2000::/3 without requiring frequent updates. The strict case 
requires keeping after it for updates, and you'd probably be better off with 
Cymru.

Thanks,
Wes George

-Original Message-
From: Brandon Applegate [mailto:bran...@burn.net]
Sent: Monday, June 14, 2010 7:38 PM
To: nanog@nanog.org
Subject: ipv6 bogon / martian filter - simple

I mean really simple.  Like 2000::/3.  If it's not in there it's bogon,
yes ?

What I'm really asking, is for folks thoughts on using this - is it too
restrictive ?

How long until it's obsolete ?

Should be a really long time no ?

Again, just looking for some feedback either way.  Would be very nice to
have a single line ACL do this job.

--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996
SH1-0151.  This is the serial number, of our orbital gun.




This e-mail may contain Sprint Nextel Company proprietary information intended 
for the sole use of the recipient(s). Any use by others is prohibited. If you 
are not the intended recipient, please contact the sender and delete all copies 
of the message.

RE: Quick IP6/BGP question

[George, Wes E IV [NTK]]

We've done it both ways.
We've found that there are sometimes issues with announcing IPv6 NLRI over IPv4 
BGP sessions depending on your chosen vendor and code version on both sides of 
the session. Specifically, we have seen some implementations where an 
IPv4-mapped IPv6 address (usually the IPv4 router-id or neighbor address) is 
announced as the next-hop, or a link-local address is used as the next-hop, or 
some random junk is announced as the next-hop, even with next-hop-self 
configured. All of these result in the receiving router dropping the 
announcements because it doesn't have a route to the next-hop. It's usually 
possible to work around this by using route policies to force the correct 
next-hop to be written on in/outbound announcements, and as we find it working 
improperly, we've been reporting bugs, but I thought it would be worth bringing 
this up as a caveat so that you can make sure your hardware/software of choice 
is behaving properly if you choose to go this route.
Also, I know of at least one vendor that didn't implement the converse 
functionality in CLI yet - it's impossible to configure an IPv6 neighbor 
address in the IPv4 address family in order to exchange IPv4 NLRI over an IPv6 
BGP session.

Thanks,
Wes George

-Original Message-
From: Thomas Magill [mailto:tmag...@providecommerce.com]
Sent: Monday, May 24, 2010 2:22 PM
To: nanog@nanog.org
Subject: Quick IP6/BGP question

From the provider side, are most of you who are implementing IP6
peerings running BGP over IP4 and just using IP6 address families to
exchange routes or doing IP6 peering?



Thomas Magill
Network Engineer

Office: (858) 909-3777

Cell: (858) 869-9685
mailto:tmag...@providecommerce.com mailto:tmag...@providecommerce.com


provide-commerce
4840 Eastgate Mall

San Diego, CA  92121



ProFlowers http://www.proflowers.com/  | redENVELOPE
http://www.redenvelope.com/  | Cherry Moon Farms
http://www.cherrymoonfarms.com/  | Shari's Berries
http://www.berries.com/





This e-mail may contain Sprint Nextel Company proprietary information intended 
for the sole use of the recipient(s). Any use by others is prohibited. If you 
are not the intended recipient, please contact the sender and delete all copies 
of the message.