Re: [ipv6-wg@ripe.net] Re: [lir-wg] IXP networks routing
PRIVATE INTERCONNECTS. Real world example follows, which is why my primary employer has a PI assignment; we interconnect using IPsec VPNs and some leased lines with a number of other enterprises. We use RFC1918 *internally* and so do many others. What addressing scheme would you suggest we use to talk, especially as we DO NOT want this traffic to accidentally leak onto the public internet ?
I notice that my reply has been conveniently ignored. Well, how will you address this issue in the *real* world ? Peter
Hi, On Wed, Mar 05, 2003 at 09:05:34AM -0000, Peter Galbavy wrote:
PRIVATE INTERCONNECTS. Real world example follows, which is why my primary employer has a PI assignment; we interconnect using IPsec VPNs and some leased lines with a number of other enterprises. We use RFC1918 *internally* and so do many others. What addressing scheme would you suggest we use to talk, especially as we DO NOT want this traffic to accidentally leak onto the public internet ?
I notice that my reply has been conveniently ignored.
Not due to malevolence, but just due to "good point. I need to think about this" reasons.
Well, how will you address this issue in the *real* world ?
I'm unsure. One could use site-local addressing, but of course as with RFC1918 addressing, the chances are high that you run into collisions. For this specific case, using non-routeable PI is also a workable approach. The tricky thing is the "non-routeable" part - the main problem with PI is "routing table growth" (and the associated "AS number burn"), which would not apply here. So maybe we need to add specific PI clauses, or let's call it differently, "non-routeable globally unique IP(v6) addresses". If we do this, we need to be careful to point out that this is *not* "the multihoming solution", but a very specific corner case that can not be properly tackled by aggregateable PA space. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57021 (57147) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Not due to malevolence, but just due to "good point. I need to think about this" reasons.
:-)
So maybe we need to add specific PI clauses, or let's call it differently, "non-routeable globally unique IP(v6) addresses".
If we do this, we need to be careful to point out that this is *not* "the multihoming solution", but a very specific corner case that can not be properly tackled by aggregateable PA space.
I think there is danger is saying "never routable" (I am not trying to change your words, just adding emphasis) as opposed to "not guarenteed routeable". I do not yet think (see below though) we need another class of address, but others may disagree. Thinking more about this, and going off the IPv6 track for a moment, if we do have a specific /8 (in IPv4 terms) that can be added to the bogon lists and shared amongst the RIRs as 'unrouted PI', this could be used for 'enterprise interconnections'. Like anything, it would of course be a scarce resource, but the filter lists would not grow by much more than a /8. Might be some mileage in it after all... Peter
Well, how will you address this issue in the *real* world ?
I'm unsure. One could use site-local addressing, but of course as with RFC1918 addressing, the chances are high that you run into collisions.
For this specific case, using non-routeable PI is also a workable approach. The tricky thing is the "non-routeable" part - the main problem with PI is "routing table growth" (and the associated "AS number burn"), which would not apply here.
So maybe we need to add specific PI clauses, or let's call it differently, "non-routeable globally unique IP(v6) addresses".
If we do this, we need to be careful to point out that this is *not* "the multihoming solution", but a very specific corner case that can not be properly tackled by aggregateable PA space.
Well, you could also argue that what Peter is trying to do is not what the intent of IPv6 is at all. The intent of IPv6 is that everyone can use public address space and we could get some interesting services working. That was ofcourse until the "let's copy RFC1918 into IPv6 and launch site-locals which preferably are globally unique" mob took over....sarcastic? me? never... But it's a good example as to why we should have ripped site-locals out... - kurtis -
Kurt Erik Lindqvist wrote:
Well, you could also argue that what Peter is trying to do is not what the intent of IPv6 is at all. The intent of IPv6 is that everyone can use public address space and we could get some interesting services working. That was ofcourse until the "let's copy RFC1918 into IPv6 and launch site-locals which preferably are globally unique" mob took over....sarcastic? me? never...
Sorry, but am I missing something ? It has been hard enough for some of us to slowly push large corporations away from requiring (companies like) us to use X.25 over leased lines to using IPsec etc. Trying to mandate those people use publicly routeable IP space for what they consider 'confidential' traffic is a non starter. And some people wonder why IPv6 will *never* make it ? (No sarcasm intended). Peter
Well, you could also argue that what Peter is trying to do is not what the intent of IPv6 is at all. The intent of IPv6 is that everyone can use public address space and we could get some interesting services working. That was ofcourse until the "let's copy RFC1918 into IPv6 and launch site-locals which preferably are globally unique" mob took over....sarcastic? me? never...
Sorry, but am I missing something ? It has been hard enough for some of us to slowly push large corporations away from requiring (companies like) us to use X.25 over leased lines to using IPsec etc. Trying to mandate those
I won't argue with you here.
people use publicly routeable IP space for what they consider 'confidential' traffic is a non starter.
Problem is that site-locals and/or RFC1918 won't make your data more secure or more confidential. Driving this fact through will be as much of a challenge as converting from X.25. The same people arguing for private addresses are also slowly realizing that they are missing a number of applications that others are using to lower costs and gain in technical advancement. Some of these people argue that the solution is to either make private addresses globally unique or require that applications developed in the IETF must support private addresses. This complexity will cost money, which is a fact that many fail to realize. IPv6 would have given us the option to start over, make a cleaner and cheaper design that is easier to maintain. Sadly we seem to be moving in the other direction. - kurtis -
Kurt Erik Lindqvist wrote:
Problem is that site-locals and/or RFC1918 won't make your data more secure or more confidential. Driving this fact through will be as much of a challenge as converting from X.25.
Sorry - my response wasn't clear as I think my point was made elsewhere in the thread - I am not interested in this aspect, but this is the aspect that drives/motivates some ludite network admins in old, slow organisations. They actually believe X.25 networks to be more secure than the 'public' Internet.
The same people arguing for private addresses are also slowly realizing that they are missing a number of applications that others are using to lower costs and gain in technical advancement. Some of
My point, to start again, is that organisations need to be able to rely on an addressing scheme that is completely independent of 'ISP of the month' that they may be using so that they can avoid try to use horrid NAT/RFC1918 hacks to talk over private (IPsec or physical) connections. It is all very cute to talk about automatic renumbering etc. but not in this context - you CANNOT do it, either technically or politically. Peter
Problem is that site-locals and/or RFC1918 won't make your data more secure or more confidential. Driving this fact through will be as much of a challenge as converting from X.25.
Sorry - my response wasn't clear as I think my point was made elsewhere in the thread - I am not interested in this aspect, but this is the aspect that drives/motivates some ludite network admins in old, slow organisations. They actually believe X.25 networks to be more secure than the 'public' Internet.
Don't tell anyone, but I have worked serving IBM systems and installations. I know more about X.25 than I want to. Been there, done that, got the ulster.
The same people arguing for private addresses are also slowly realizing that they are missing a number of applications that others are using to lower costs and gain in technical advancement. Some of
My point, to start again, is that organisations need to be able to rely on an addressing scheme that is completely independent of 'ISP of the month' that they may be using so that they can avoid try to use horrid NAT/RFC1918 hacks to talk over private (IPsec or physical) connections. It is all very cute to talk about automatic renumbering etc. but not in this context - you CANNOT do it, either technically or politically.
This is another issue though. portable addressspace, or PI, or what we want to call it is something that IPV6 is missing. And that is a problem. Just like multihoming. I agree that automatic renumbering won't get us anywhere, we need to solve the real problem. And Site-locals will not help. - kurtis -
PRIVATE INTERCONNECTS. Real world example follows, which is why my primary employer has a PI assignment; we interconnect using IPsec VPNs and some leased lines with a number of other enterprises. We use RFC1918 *internally* and so do many others. What addressing scheme would you suggest we use to talk, especially as we DO NOT want this traffic to accidentally leak onto the public internet ?
I notice that my reply has been conveniently ignored. Well, how will you address this issue in the *real* world ?
Link-local? It's not ideal but should work. - kurtis -
participants (3)
-
Gert Doering -
Kurt Erik Lindqvist -
Peter Galbavy