"Depending on putting devices on 1918 for security is dangerous. " -
Simon J. Lyall.
Agreed. RFC 1918 is a good idea, it's not the law, and with that ISP's
are not required to do anything about 1918 addr's if they choose not to.
We receive a disturbingly large amount of traffic sourced from the 1918
space destined for our network coming from one of our normally
respectable Tier 1 ISP's (three letter acronym, starts with 'M', ends
with 'CI').
This is particularly irritating since we pay for burstable service; nice
that we are paying for illegitimate traffic to come down our pipes.
Their answer to this issue was: our routers can't handle the additional
load that filtering 1918 traffic would cause.
That's odd, I didn't think routing to Null0 (or equivalent) was all that
taxing, I don't want an ACL, I want it gone in the cheapest, fastest way
possible.
With that it our (the global collective, not just my company)
responsibility to prevent RFC 1918 traffic from entering our exiting our
border; makes for an interesting definition of "private address space."
Null routes aren't going to stop packets with 1918 *sources* from
entering your network, I'm afraid. This is where ACLs come into
play.
And it's quite conceivable, on a network of MCI's size, there are
still peering and edge ports terminated by GSRs with engine 0 cards,
or 7500s, or other hardware where bogon filtering and/or reverse-path
validation really is a Big Deal(tm).
-a
(computing VJ's cell phone bill on the WRT54G as we speak)
Hello. I felt I had to write a small comment to this.
For the record, we use 1918 address range on several of our public routers meaning you will get legitimate traffic from this address space, atleast from us unless you are filtering it (which is of course all your decision). Filtering any type of traffic at all by a transit provider without the possibility to remove these filters _could_ be reason enough for us to terminate the contract with them since we would feel we were not paying for real internet connectivity.
For the record, we use 1918 address range on several of our public routers
meaning you will get legitimate traffic from this address space, atleast
from us unless you are filtering it (which is of course all your decision).
Filtering any type of traffic at all by a transit provider without the
possibility to remove these filters _could_ be reason enough for us to
terminate the contract with them since we would feel we were not paying for
real internet connectivity.
perhaps you would benefit reading rfc 1918, and the prohibition of
propagating 1918 space to the global net, before redifining 'real
internet connectivity.' most of us would consider it a privilege
not to have you as a customer.
>> We receive a disturbingly large amount of traffic sourced from the 1918
>> space destined for our network coming from one of our normally
>> respectable Tier 1 ISP's (three letter acronym, starts with 'M', ends
>> with 'CI').
>>
>> This is particularly irritating since we pay for burstable service;
nice
>> that we are paying for illegitimate traffic to come down our pipes.
Hello. I felt I had to write a small comment to this.
For the record, we use 1918 address range on several of our public routers
meaning you will get legitimate traffic from this address space, atleast
from us unless you are filtering it (which is of course all your
decision).
Filtering any type of traffic at all by a transit provider without the
possibility to remove these filters _could_ be reason enough for us to
terminate the contract with them since we would feel we were not paying
for
real internet connectivity.
funny. you must be talking about a different internet. i hear there have
been 'rumours out on the internets [sic]', maybe i'm just behind the times..
<g>
all jokes aside, 1918 allows for use of 1918 space in a private network or a
'private internet [sic]' comprised of any such number of private networks as
agree to interconnect and cooperate in routing traffic sourced from and
destined to said space. it follows that any 1918-sourced traffic you send me
is illegitimate. out of curiosity, what kind of 'legitimate traffic',
considering i couldn't legitimately reply back, were you speaking of?
all jokes aside, 1918 allows for use of 1918 space in a private network
or a 'private internet [sic]' comprised of any such number of private
networks as agree to interconnect and cooperate in routing traffic
sourced from and destined to said space. it follows that any 1918-sourced
traffic you send me is illegitimate. ...
seems like rfc1918's prohibitions are not effective (and are unenforceable).
i hope that there will be no more ops-relevant specs with harmful potential
side-effects and ineffective+unenforceable prohibitions against those.
and of course, see BCP38 (or if you're in management, SAC004).
> all jokes aside, 1918 allows for use of 1918 space in a private network
> or a 'private internet [sic]' comprised of any such number of private
> networks as agree to interconnect and cooperate in routing traffic
> sourced from and destined to said space. it follows that any
1918-sourced
> traffic you send me is illegitimate. ...
right, like this junk:
--- snip ---
seems like rfc1918's prohibitions are not effective (and are
unenforceable).
i hope that there will be no more ops-relevant specs with harmful
potential
side-effects and ineffective+unenforceable prohibitions against those.
i tend to view it as a subclass of spoofing, more specifically spoofing
through stupidity/misconfiguration. the only difference i see between
someone fat-fingering an ip address and this is, as is to be (sadly)
expected, that some folk abuse 1918 as a basis to argue correctness in such
cases. while i'm sure we can all agree that we would have liked to have less
implied trust engineered into designs when those rfcs were penned, this is
probably one of the least damaging cases and i tend to think that
enforcement of 1918 belongs elsewhere, ie ipv# and bcp38.
and of course, see BCP38 (or if you're in management, SAC004).
given the track record of bcp38 and fiery debate resulting from the mention
thereof on nanog-l, i propose to tack it onto the local list of corollaries
of godwin's law <g>
We simply did not want the routers to be globally available nor revealing the ownership due to security reasons, but still permit that other half to receive diagnostic data. If you must get into further details please let us discuss it off the list.
This thread was started by Leo Bicknell on Mon Nov 08 14:28:16 2004. The
original post stated:
"The IETF IPv6 working group is considering two proposals right now
for IPv6 "private networks". Think RFC-1918 type space, but redefined for
the IPv6 world. Those two drafts can be found at:
"Since this is a list of providers, I encourage you to read the
drafts, and submit your comments to the working group. The information for
the working group is at http://www.ietf.org/html.charters/ipv6-charter.html,
and includes their mailing list archives and information on how to subscribe
and/or post."
"Even if you disagree with me, much like voting the important thing
is that you voice your opinion."
As Leo said, these two drafts are under consideration by the IP Version 6
Working Group (ipv6). Mail list information is:
Looking at the archives for the working group there has been no recent
discussion of these drafts. In the past two days there have been over 80
posts to this thread. This is a valuable discussion but to a large extent
the efforts can be considered as a non input into the working group as the
discussion is not on their mail list. The IETF works best when people
directly contribute to the discussion and consensus building process. I
encourage you to move this discussion to the working group mail list and if
you are at the IETF to attend the IPv6 Working Group at 9 AM, Thursday
morning in the Georgetown room. The session is also multicast.
... This is a valuable discussion but to a large extent
the efforts can be considered as a non input into the working group as the
discussion is not on their mail list. The IETF works best when people
directly contribute to the discussion and consensus building process. I
encourage you to move this discussion to the working group mail list and
if
you are at the IETF to attend the IPv6 Working Group at 9 AM, Thursday
morning in the Georgetown room. The session is also multicast.
I second Ray's comments about participation here. At the same time as you
read and form your opinions, make sure you take off your blinders about how
things were done in the good old days. Many current network deployments are
work-arounds to the limitations of existing technology. There are
opportunities for different configurations going forward that achieve the
real goals. To that end, you should also read and comment on:
draft-vandevelde-v6ops-nap-00.txt
Another point to consider is that most of the people that would be using the
ULA space are NOT service providers. As such you should keep in mind that
the target user's problem is not the same as most of the membership of this
list, so the tools and their use are not the same. While everyone could
request space from a provider or Arin for private use, having a clean single
well-known bogon filter of FC00/7 makes everyone's life much simpler. Since
most of the problems in the operational world are derived from unnecessary
complexity, having a simple well understood filter should lead us to a more
stable network. Yes we know people leak 1918 today and ULAs don't prevent
leaks, but leaks of space that was not intended to be globally routed will
be even more common if they are non-contiguous random pieces from each
customer.
"Depending on putting devices on 1918 for security is dangerous. " -
Simon J. Lyall.
Agreed. RFC 1918 is a good idea, it's not the law, and with that ISP's
are not required to do anything about 1918 addr's if they choose not to.
We receive a disturbingly large amount of traffic sourced from the 1918
^^^^^^^
That's odd, I didn't think routing to Null0 (or equivalent) was all that
taxing, I don't want an ACL, I want it gone in the cheapest, fastest way
possible.
that's odd... routing is a DESTINATION based problem, not a SOURCE based
one.
"Depending on putting devices on 1918 for security is dangerous. " -
Simon J. Lyall.
Agreed. RFC 1918 is a good idea, it's not the law, and with that ISP's
are not required to do anything about 1918 addr's if they choose not to.
We receive a disturbingly large amount of traffic sourced from the 1918
^^^^^^^
That's odd, I didn't think routing to Null0 (or equivalent) was all that
taxing, I don't want an ACL, I want it gone in the cheapest, fastest way
possible.
that's odd... routing is a DESTINATION based problem, not a SOURCE based
one.
Routing has always been more than a destination based decision. Even in the beggining IP had LSRR/SSRR.
Now it has policy/qos/SAV/urpf what have you.
<Tinfoil Hat>
The redefinition of ip routing as actions based solely on the destination address in the packet was done merely by those wishing to ignore performance requirements for doing it properly. They took the cheap easy way out.
Kudos to all you grizzled folk out there who handed out those free passes. (After 20 years of IP we now offer line rate X as long as you dont do Y!)
</TH>
Sure, ip-options bits were/are allowed for LSRR/SSRR, which as you said
below is disabled for a multitude of reasons on many/most/all (?) large
parts of the Internet for many reasons, not the least of which is
performance penalties. So, aside from the 2 examples routing ip has been a
hop-by-hop destination based problem, source addresses (even with
LSRR/SSRR I believe) has little to do with the equation.
I could be wrong, I am just a chemical engineer. If this was a
distillation column or a raction vessel I might be more sure :
I could be wrong, I am just a chemical engineer. If this was a
distillation column or a raction vessel I might be more sure :
actually, i think you happen to be one of the maybe 25% of
participants in this discussion that is an actual operator
on a real network. rarer and rarer.
and if nanog ain't a reaction vessel, what is? and i suspect
a number of participants are too near distillations when they
type.
> I could be wrong, I am just a chemical engineer. If this was a
> distillation column or a raction vessel I might be more sure :
actually, i think you happen to be one of the maybe 25% of
participants in this discussion that is an actual operator
on a real network. rarer and rarer.
I see its time to quit then!
and if nanog ain't a reaction vessel, what is? and i suspect
a number of participants are too near distillations when they
type.
Seriously though, Leo's note and concerns about private-use ipv6 are real
issue. I think I'll read (two more days of ipv6 hell it seems) the ietf
lists and send some comments their way. As an operator (security wonk
really despite my love of the distillation and reaction equipments) there
are 'good' and 'bad' in the private addressing schemes.
Good: "allows people to keep their privates private" (basically)
"permits people to have test and devel systems without wasting
public space"
Bad: "more hell of 1918"
"clashes where we wouldn't expect, when we can't afford, with folks
we didn't know"
"less 'waste' for private peoples"
