[6bone] non-global address space for IXs (was: 2001:478:: as /48)
Jeroen Massar
jeroen@unfix.org
Sun, 7 Sep 2003 02:10:53 +0200
-----BEGIN PGP SIGNED MESSAGE-----
John Fraizer [mailto:tvo@EnterZone.Net] wrote:
> On Sat, 6 Sep 2003, Jeroen Massar wrote:
>
> > > OK. So in an exchange point situation, where you are
> > > connecting to a L2 fabric and using a common network so you
> > > can make use of a
> > > route-server and not be required to have N^2 BGP sessions to have
> > > redundancy, how do you propose this happen? You just added MORE
> > > complexity to use a route-server rather than taking it away.
> >
> > The most usual and easiest way is a switch with a prefix (/64).
>
> And that /64 (or /48 as it may be) is a connected route. It becomes a
> *seemless* fusion between ASNs. Nexthops are handed out by the Route
> Server and no further intervention is required on the part of
> participants. The nexthop is part of the IX address space, which is a
> *connected* route. No static routes required. On the other
> hand, if that address space is not globally routed, it breaks PMTU-Disc,
> traceroute, etc.
You are talking about a route server which I never mentioned.
Maybe an example makes it clear what I mean in JunOS style
from the top of my head, didn't test it as I don't have a
bedside juniper </sarcasm>:
interface lo0 unit 0 family inet6 address 2001:db8:2000::1/64;
interface fe-0/1/0 unit 0 family inet6 address 2001:db8::1/64;
protocols bgp group MyPeer {
type external;
family inet6 unicast;
peer-as 65535l
neighbour 2001:db8::2;
next-hop 2001:db8:2000::1;
}
Tada, BGP peering established, if the other side sets it up too.
2001:db8::/64 == IX prefix
2001:db8:2000::/64 is out of the providers space, should be
a seperate TLA but there is only one documentation /32.
All traffic going out of this box will have a source IP of
2001:db8:2000::1 which is globally reachable. Only the
peers will talk to each other using 2001:db8::/64.
This doesn't hurt traceroutes either as they have the ISP's
IP and not the IX's IP, no problems with pathmtu etc...
Another advantage of this is that "abuse" type reports
won't go to the IX, but to the ISP as there is no IX space
to be seen anywhere.
But you did know that ofcourse, I am the kid here :)
Glad to see at least one person not thinking I am not yet
another old fart, thanks for the positive comment.
Maybe that clears up what I mean?
Or maybe you where just to angry to be able to read what
I was talking about? Please cool down a bit, stop the caps,
drink some cold beer and try again.
> > That prefix doesn't need to be seen in any BGP table, only as
> > a static route on the router itself. As you can use a loopback
> > address, from that router's owner own space and which is globally
> > routable as a nexthop and there is also no problem whatsoever
> > with traceroutes etc. This is why we have IX space and why it
>
> Usingt owner address space requires that static routes be
> added for every peer. Which part of "Peering at an exchange
> point is *easier* than multiple bilateral peering sessions"
> did you not understand when the virtues of IX's were explained?
According to you everything, then again you didn't understand
what I meant, thus this comment is quite futile.
> Look. If you want to do it in a broken, antiquated way, that is just
> fine. Don't expect us to do so. If you want to filter the
> address space used for IX's managed by EP.NET, that is just fine.
> Stop bitching and moaning though. You quite OBVIOUSLY have much
> less experience in the arena than myself, let alone Bill and simply
> want to bitch and moan and see your own emails echoed by the list.
> Get over yourself.
Wow, another personal attack without content and absolutely not
refering to anything I said but only things you made up.
> > Great example why you don't want to have IX prefixes in BGP and
> > should actually be actively filtering them and complaining to
> > the people redistributing is a case where the switching fabric
> > goes down, you receive the IX prefix over your transit and
> > suddenly all your bgp sessions go over transit, neat ;)
>
> No. Actually, that is a great example of YOU not understanding how to
> properly configure your BGP sessions and preferences. Don't
> expect us to make changes to accomodate your being void of appropriate clue.
And another one, if I am apparently missing clue, why don't
you as the one who apparently does know what you are talking
about point me to the clue, any good hints of books I need
to read, any URL's?
> > > Bill never *DEMANDED* that anyone accept 2001:478:: prefixes
> > > at all.
> >
> > He didn't demand it, but apparently he does request it between
> > the lines. I never saw anybody else mention anything about the
> > prefixes they where announcing in the IPv6 world. Thus what
> > else would be the intention except for mailinglist filling?
>
> You, Son, are the one who appears to be interested in Mailing list
> filling. If you don't want to accept the /48 that's *FINE*
> but, I *BEG OF YOU!!!* GET OVER YOURSELF! Drop it. I couldn't
> give a rats ass if you carry the /48 we use at ISI-LAP.
> I'm serious. Get over yourself and DROP IT!
Oeh I have been promoted to "Son". Sorry that I tend to respond
to many messages and try to figure out why certain actions
are taken which affect many people, who mostly keep silent.
If you don't care, why do you even bother to reply?
You are still missing the point about _why_ I made the initial
comment. Please re-read the messages, but have that cold beer first
you seem to be quite flamy at the moment.
> > > He simply made the same announcement that he has for the
> previous two
> > > years: Don't expect to see this one as a /32 but rather as
> > > /48's, IF you see it at all.
> >
> > Currently GRH sees the following:
> >
> > 2001:478::/45 2001:1418:1:400::1 12779 3549 6939 109
> 4555 IGP
> > 2001:478::/45 2001:610:25:5062::62 1103 11537 6939 109
> 4555 IGP
> > 2001:478::/45 > 2001:470:1fff:3::3 6939 109 4555 IGP
> > 2001:478::/45 2001:610:ff:c::2 1888 1103 11537
> 6939 109 4555 IGP
> > 2001:478:65::/48 2001:1418:1:400::1 12779 3549 6939 109
> 4555 IGP
> > 2001:478:65::/48 2001:610:25:5062::62 1103 11537 6939 109
> 4555 IGP
> > 2001:478:65::/48 > 2001:470:1fff:3::3 6939 109 4555 IGP
> > 2001:478:65::/48 2001:610:ff:c::2 1888 1103 11537
> 6939 109 4555 IGP
> >
> > Hmmm a /45 is not a /48 last time I did my math test.
> > So there are aggregates? Why don't make it that nice /32 then
> > if you want it to be visible.
>
> Again, get over yourself. Filter your ass off. I don't care. Just
> frigging DROP IT!
Why? Because you can't stick to your arguments?
Check Bill's message, he did admit that it was a typo.
Is it so hard to accept that one time in your lifetime you are
not right? I have been wrong quite a number of times, but at
least I can admit that if people come with good arguments.
And you have absolutely none of those except loads of flames.
> > If you don't want it to be visible, then why don't you slap on
> > a no-export (okay, which gets dropped by some) or simply don't
> > distribute it to BGP?
>
> If you don't want to accept it, why don't you filter it?
> Just recently, someone posted about people not honoring no-export
> yet, you want us to use it?
Hmm is my english that bad? Let's rephrase the story I also
told at RIPE46 during the IPv6 WG:
AS1200 (AMS-IX) is announcing 2001:7f8:1::/48 to it's peers
with the no-export flag set. Thus one would expect that it
will only be visible at their peers, those directly connected
to the IX. But apparently the flag gets overruled by some:
2001:7f8:1::/48 2001:8e0:0:ffff::4 8758 25396 25396 25396 25396 6939 3257 1200 IGP
2001:7f8:1::/48 2001:470:1fff:3::3 6939 3257 1200 IGP
2001:7f8:1::/48 2001:780:0:2::6 12337 5539 3257 1200 IGP
2001:7f8:1::/48 2001:1418:1:400::1 12779 3549 1200 IGP
And suddenly it is visible all across the world (6939 is HE.net)
Which was not the intention of the originator.
It could be that this is a software or a configuration bug.
Either way, I think it is quite important that it gets fixed.
You are probably one of the people best known with most of
the problems seen with Zebra, those problems do exist elsewhere too.
And I like to point out problems and get them straightend out.
> Sheesh. Make up your mind.
The one who can't make up his mind would be you in this case.
Bill announces that it could be that only /48's and possibly
in the future only /64's are to be seen from the EP.net block.
Thus in http://mailman.isi.edu/pipermail/6bone/2003-September/007890.html
I ask why he doesn't use the RIR IX block's or announce the /32
so that they are globally reachable, which apparently is wanted.
And suddenly I am a kid for asking such a sort of thing and pointing
out that some policies exist for those things?
Bill doesn't have this argument apparently as he doesn't respond
to these messages, he made his note and explained why he did that
You on the other hand are the flamy one and you definitly care.
> > > If you don't like it, filter it. I could care less, as I'm sure Bill
> >
> > You could care less, so you actually care, I'll take that is a typo ;)
> >
>
> I *COULD ***NOT*** CARE LESS IF MY TRAFFIC MAKES IT IN AND OUT OF YOUR
> PO-DUNK, WANNA-BE, WISH I WAS A REAL PROVIDER* network. Does
> that make it clear enough for you?
The capslock was on apparently, it's at the left of your keyboard.
I said I took that as a typo didn't I? I really understand that you
don't like me, for some reason or another.
> > attempts of trying to make it into a flamewar. It just shows
> > that you don't have any argument in your advantage.
> > I don't swear, I hope you can deal with that too.
>
> There is no argument. If you don't want to accept the routes, you don't
> have to. You're wasting our time, and bandwidth with your constant
> whining and rehashing of the same bullshit. DROP IT, you CHILD!
Your real network has problems with messages of ~8kb?
If you don't want to reply or want to see my messages,
you don't need to, you can filter them very easily, see below.
> > On one hand you say you want it visible, why else does it get
> > announced and on the other hand you don't care, oddness...
>
> I don't care if YOU can see it. You see, you, believe it or
> not, have the power to NOT accept the prefix. If you don't want
> to, you don't have to accept it. Deal with it.
Which is exactly what most european operators are doing at the
moment. Which is the reason why I simply asked why the /32
wasn't announced if you apparently do require it
(yes I am repeating myself, but hey you don't read, so I have to)
> > But I am probably just a whi... bit... and a moa...
> > Personal attacks don't do the content of your message any good.
>
> And whining and bitching and moaning don't do you any good
> either. If you don't want to accept the prefixes, don't accept
> them but for GODS SAKE, stop your frigging whining about it!
>
> > I never had the intention of making you, apparenty that would
> > require force anyways. My intention was making clear that the prefix
> > you are using is *nothing special*, which apparently you are trying to
> > convince to everybody, but it isn't.
>
> Nobody tried to convince anyone that the prefix was special.
> It is being used in a non-conventional way and that was pointed out so
> that those who DESIRED to accept the prefix would KNOW that it was LEGIT.
Are you saying that you know of any prefix currently being announced
that is not "legit"? Please note them to us here on the list so that
we can take action *now*. Hijacking is a bad thing.
Currently the only really wrong things being seen in the GRT:
3ffe:1300::/24 Mismatching origin ASN, should be 762 (now: 10318)
3ffe:2f00::/24 Mismatching origin ASN, should be 2547 (now: 1955)
3ffe:8070::/28 Mismatching origin ASN, should be 278 (now: 237)
Note that in case of the 3ffe:1300::/24 the single contact that
is in the whois database is not reachable, next to that 10318 isn't
NORTEL but a rather rogue AS which is not contactable either.
3ffe:2f00::/24 probably just didn't update their whois object.
3ffe:8070::/24 is all of a sudden sourced from MERIT, while 278
which should be announcing it is a Mexican University.
Then there are also 6to4 more specifics which simply violate the RFC:
2002:8c6d:106::/48 More specific 6to4 prefix (140.109.1.6/32)
2002:c0e7:d405::/48 More specific 6to4 prefix (192.231.212.5/32)
2002:c2b1:d06e::/48 More specific 6to4 prefix (194.177.208.110/32)
2002:c8a2::/33 More specific 6to4 prefix (200.162.0.0/17)
2002:c8c6:4000::/34 More specific 6to4 prefix (200.198.64.0/18)
2002:c8ca:7000::/36 More specific 6to4 prefix (200.202.112.0/20)
And a *lot* of more specifics in all the other spaces.
Thus 111 prefixes are currently 'superfluos'.
Any other takers?
Before you say "filter them then", for GRH I explictly request
unfiltered prefixes, so we can see where they are coming from.
One can't force anybody, but we can make people aware that sooner or
later the routing tables *are* going to explode or just filled with crap.
Thinking of Iljitsch talk last thursday mentioning what would happen
when 10 million people started announcing their /48 ;)
Then again, that's perfect for companies like C and J and not to
forget all the memory vendors.
> > Now you are, between the lines, requesting that everybody not filter
> > your prefix, tomorrow some other nitwit comes along and simply invents
> > some /32 from which he/she/it is going to do "multihomed prefixes" and
> > requests that everybody allows it accross the world. If you want to
> > change policy, then bring it to the policy department.
>
> When did ANYONE request that it not be filtered? Bill simply notified
> that the prefix would appear as /48's. He didn't say, "Please don't
> filter this." It was a "For your information" post. DEAL WITH IT!
If he really meant what you are saying, but these are your words,
then why was that message required? People who apply filters are
already applying filters, it's their network and they will filter.
(yups, another repeat)
I've dealt with it a long time ago and have noted it a couple of
times too as you might have noticed. We simply filter. But apparently
you don't like it when you 'inform' people that you announce and
we inform you that we filter and provide a solution to overcome your
problem of still being reachable, which was the thing I read between
the lines. You mentioned that when it gets filtered that it breaks
a number of things, so what else is there to think?
Trying to be a helping hand is not appreciated apparently.
I'll remember that next time "when I've grown up" in your wordings.
> > I actually also am starting to wonder why this has been brought up
> > on the 6bone mailinglist and not on for example v6ops as it is RIR
> > space we are talking about here. But that is next to the point.
>
> You just want to complain, don't you? Which ASNs do you
> control? I want to update my "Bitch filters".
"whois JRM1-RIPE", use google on my full name, have fun with it.
You care enough to do that and have enough time for it too.
If you really hate me so much and think I am all that childish
maybe you could just stick me in your email filter list or simply
ignore me. FYI I only use jeroen@unfix.org for mails sent out by
me, not related to a organisation and the procmail rule would be:
:0:
* ^From: Jeroen Massar <jeroen@unfix.org>
/dev/null
Thank you for showing you are a real american :)
Maybe I'll add you to /dev/null, then again it's quite funny
to see someone go ballistic over such a stupid thing that
he can't even argue about :)
Greets,
Jeroen
PS: No offense to the other americans, but they probably
are not reading this thread any more as it only contains
a lot of flames :(
-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/
iQA/AwUBP1p3jCmqKFIzPnwjEQKmOwCdHu/HK77gFvFwBLnhrDYtvhGsXoUAnA++
26+FLH2zUcrRJUOwfbEv+r2j
=hNDh
-----END PGP SIGNATURE-----