From tkapela at gmail.com Fri Jun 1 00:44:37 2012
From: tkapela at gmail.com (Anton Kapela)
Date: Fri, 1 Jun 2012 00:44:37 -0500
Subject: The Tubes
Message-ID: <8359821217392369125@unknownmsgid>
All,
Andrew Blum was interviewed on NPR's Fresh Air this week -- and gets a
lot right about the Tubes we built.
FYI, because your boss will be asking you about it:
http://m.npr.org/story/153701673?url=/2012/05/31/153701673/the-internet-a-series-of-tubes-and-then-some
-Tk
From hmurray at megapathdsl.net Fri Jun 1 01:03:06 2012
From: hmurray at megapathdsl.net (Hal Murray)
Date: Thu, 31 May 2012 23:03:06 -0700
Subject: Wacky Weekend: The '.secure' gTLD
Message-ID: <20120601060306.D6C6A80003B@ip-64-139-1-69.sjc.megapath.net>
> I think this is an interesting concept, but i don't know how well it will
> hold up in the long run. All the initial verification and continuous
> scanning will no doubtingly give the .secure TLD a high cost relative to
> other TLD's.
Right. But your "high cost" is relative to dime-a-dozen vanity domains
and/or domains for small/tiny businesses. That's not their target market.
How much would it be worth to a bank if they could keep a few of their
customers from being scammed? How much would it be worth to an ISP if they
could keep a few of their customers from being phished? For starters, just
consider the support costs.
Here is a note from a different context that says it only costs $99 for
Verisign to certify you to sign secure-boot stuff for Windows 8, so I think
that's the right ballpark.
http://mjg59.dreamwidth.org/12368.html
I'm assuming that the hard part is the initial verification, not the ongoing
monitoring that can be automated. YMMV. I might be all wet. ...
--
These are my opinions. I hate spam.
From danny at danysek.cz Fri Jun 1 03:19:16 2012
From: danny at danysek.cz (Daniel Suchy)
Date: Fri, 01 Jun 2012 10:19:16 +0200
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <20120531170646.GA2477@pob.ytti.fi>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
<088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
<4FC77434.5000306@foobar.org>
<1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
<20120531170646.GA2477@pob.ytti.fi>
Message-ID: <4FC87B04.20200@danysek.cz>
On 05/31/2012 07:06 PM, Saku Ytti wrote:
> On (2012-05-31 08:46 -0700), David Barak wrote:
>
>> On what precisely do you base the idea that a mandatory transitive attribute of a BGP prefix is a "purely advisory flag which has no real meaning"? I encourage you to reconsider that opinion - it's actually a useful attribute, much the way that MED is a useful attribute. Many providers re-write MED, and apparently some re-write ORIGIN. Neither of those is "network abuse" - it's more accurately described as "network routing policy." As has been stated here before: your network, your rules.
>
> When provider rewrites MED, they do it, because they don't want peer to
> cause them to cold-potato, to which they may have compelling reason.
> Then some clever people realise they forgot to rewrite origin, working
> around the implicit agreement you had with them.
>
You CAN rewrite MED, as stated in RFC 4271, section 5.1.4 - but you
SHOULD NOT change origin attribute, as stated in section 5.1.1. So, in
terms of rewriting, MED is not comparable to origin.
I think RFC 4271 (http://tools.ietf.org/html/rfc4271) is very clear
here. Back to the standard, why condone it's violation? Yes, statement
about origin is here since January 2006 - older RFC 1771 didn't contain
similar rule. But 6 years after publishing I think everyone had enough
time to implement this correctly.
I still think, that professionals shoult follow RFC and not insert their
own creativity to places, where's not expected - just because they
decide that as a "cool" idea. For local routing policy - there're still
lot of knobs, which can be used internally (typically MED, LOCPREF) to
enforce expected policy and there's technically no reason to change origin.
--
Daniel
From saku at ytti.fi Fri Jun 1 03:28:00 2012
From: saku at ytti.fi (Saku Ytti)
Date: Fri, 1 Jun 2012 11:28:00 +0300
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <4FC87B04.20200@danysek.cz>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
<088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
<4FC77434.5000306@foobar.org>
<1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
<20120531170646.GA2477@pob.ytti.fi> <4FC87B04.20200@danysek.cz>
Message-ID: <20120601082800.GA19206@pob.ytti.fi>
On (2012-06-01 10:19 +0200), Daniel Suchy wrote:
> I think RFC 4271 (http://tools.ietf.org/html/rfc4271) is very clear
> here. Back to the standard, why condone it's violation? Yes, statement
It's extremely hard to find RFC which does not contain incorrect
information or practically undeployable data. Many things if reading RFC
anally are not standard compliant, like no one does IPv6 in the world and
no one does MPLS VPNs etc.
I'm repeating myself, but if you reset MED, you do it because you have
reason why you do not allow peer to force you to cold-potato. There is
little point in resetting MED and not resetting origin, as what you tried
to stop from occurring still occurs.
--
++ytti
From tknchris at gmail.com Fri Jun 1 06:06:54 2012
From: tknchris at gmail.com (chris)
Date: Fri, 1 Jun 2012 07:06:54 -0400
Subject: The Tubes
In-Reply-To: <8359821217392369125@unknownmsgid>
References: <8359821217392369125@unknownmsgid>
Message-ID:
for those who want to read or download, here are some easier links
non mobile link:
http://www.npr.org/2012/05/31/153701673/the-internet-a-series-of-tubes-and-then-some
direct mp3:
http://npr.vo.llnwd.net/kip0/kip0/_pxn=0+_pxK=17273+_pxE=mp3/anon.npr-mp3/npr/fa/2012/05/20120531_fa_01.mp3?orgId=1&topicId=1033&dl=1
On Fri, Jun 1, 2012 at 1:44 AM, Anton Kapela wrote:
> All,
>
> Andrew Blum was interviewed on NPR's Fresh Air this week -- and gets a
> lot right about the Tubes we built.
>
> FYI, because your boss will be asking you about it:
>
>
> http://m.npr.org/story/153701673?url=/2012/05/31/153701673/the-internet-a-series-of-tubes-and-then-some
>
> -Tk
>
>
From jcurran at istaff.org Fri Jun 1 06:46:30 2012
From: jcurran at istaff.org (John Curran)
Date: Fri, 1 Jun 2012 07:46:30 -0400
Subject: Accuracy of RFCs (was: Re: HE.net BGP origin attribute rewriting)
In-Reply-To: <20120601082800.GA19206@pob.ytti.fi>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
<088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
<4FC77434.5000306@foobar.org>
<1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
<20120531170646.GA2477@pob.ytti.fi> <4FC87B04.20200@danysek.cz>
<20120601082800.GA19206@pob.ytti.fi>
Message-ID: <344DD3D8-1E14-40C6-9D18-0984A235C17A@istaff.org>
On Jun 1, 2012, at 4:28 AM, Saku Ytti wrote:
> It's extremely hard to find RFC which does not contain incorrect
> information or practically undeployable data.
Actual errors in RFC's (typos, incorrect references, etc.) -
Differing views regarding RFC subject material; feel free to
work with others of similar to write up your perspective -
The RFC series is an Internet-wide community effort.
Thanks!
/John
From brunner at nic-naa.net Fri Jun 1 07:46:06 2012
From: brunner at nic-naa.net (Eric Brunner-Williams)
Date: Fri, 01 Jun 2012 08:46:06 -0400
Subject: Wacky Weekend: The '.secure' gTLD
In-Reply-To: <20120601025243.53806.qmail@joyce.lan>
References: <20120601025243.53806.qmail@joyce.lan>
Message-ID: <4FC8B98E.8010906@nic-naa.net>
On 5/31/12 10:52 PM, John Levine wrote:
>> What will drive the price up is the lawsuits that come out of the
>> >woodwork when they start trying to enforce their provisions. "What? I
>> >have already printed my letterhead! What do you mean my busted DKIM
>> >service is a problem?"
> History suggests that the problem will be the opposite. They will
> find that the number of registrations is an order of magnitude less
> than their worst case estimate (a problem that every domain added in
> the past decade has had), and they will make the rules ever looser to
> try to gather more registrations and appease their financial backers
> until it's yet another meaningless generic TLD.
agree.
> For concrete examples, see what happened to .AERO, .TRAVEL, .PRO, and
start with .biz as its re-purposing occurred first.
> of course the race to the bottom of first regular SSL certificates,
> and now green bar certificates.
>
> What might be useful would be .BANK, with both security rules and
> limited registrations to actual banks. Identifying banks is
> relatively* easy, since you can use the lists of entities that
> national bank regulators regulate.
agree. proposed by core. opposed by aba.
> R's,
> John
>
> * - I said relatively, not absolutely.
even within the financial services industry, useful taxonomies exist,
e.g., ethical banks, islamic banks, depositor owned cooperative banks,
... again, proposed by core. opposed by aba. and you _were_ on the
high security generic top-level domain working group where you pushed
for anti-spamdom and i for forms of "more secure banking".
-e
From jimmys at myesn.com Fri Jun 1 08:51:17 2012
From: jimmys at myesn.com (Jimmy Sadri)
Date: Fri, 1 Jun 2012 06:51:17 -0700
Subject: Comcast IPv6 Update
In-Reply-To:
References:
Message-ID:
Jason,
I remembered this post and decided to check on the status of this
for World Ipv6 day coming up in on the 5th of this month and so I called
Comcast bussiness support... what a nightmare... the first guy told me that
I already have static IP address so why do I need Ipv6 addresses?
Then he told me that I can still "surf the Internet" with Ipv4 addresses and
I don't need Ipv6 addresses. I asked to speak to someone who
knows more about the Ipv6 rollout he then told me that there is nothing to
know. I tried to get him to "escalate it" as you suggested below
but he refused telling me that a request for Ipv6 addresses is not a valid
technical reason to escalate. He did offer to let me speak to his
supervisor. His supervisor wasn't much better. I explained to him how I
have been following things on comcast6.net and with Ipv6 day coming
up I thought maybe there had been somekind of forward progress on deployment
and could he at least point me in the right direction for someone
to talk to about it. He then told me that there is no such person and that
if there was such a person that Comcast's Ipv6 rollout plans and
locations are proprietary information not to revealed to customers like me.
I referenced NANOG and the below post and was told first that
how do I know that person is actually a Comcast employee? I guess besides
the addresses from you guys @cable.comcast.com I don't know for sure
that you guys are actually Comcast employees I just asume that you are who
you say you are. For the record I don't doubt that you guys work for
Comcast but then the supervisor tells me that even IF the people I
referenced DO work for Comcast that they are in violation of company policy
for speaking in a public forum and claiming to work for Comcast...
Wow... I just wanted some info on deployment scheduling and possilbe
timelines for getting Ipv6 and I get all that. Gotta say they could really
do better in the customer service dept. I wonder if you guys have any more
info on this or can at least point me in the right direction... like I
said I already tried Comcast Business Support with the above results... so I
guess if you can help find out this before World Ipv6 day so that I
could participate that would be ideal... I wonder if anyone else has tried
getting this info on the list with better results?
- Jimmy
-----Original Message-----
From: Livingood, Jason [mailto:Jason_Livingood at cable.comcast.com]
Sent: Wednesday, November 09, 2011 8:58 AM
To: Blake T. Pfankuch; Brzozowski, John; NANOG
Subject: Re: Comcast IPv6 Update
On 11/9/11 11:54 AM, "Blake T. Pfankuch" wrote:
>This appears directed at the Home market. Any word on the Business
>Class market even as a /128?
Business Class is coming later. It won't hurt to contact the Business Class
sales number and ask about IPv6 (and tell them to escalate it) - it all
helps get us internal support and buy in. It is definitely on our radar
though.
- Jason
From jared at puck.nether.net Fri Jun 1 08:56:21 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Fri, 1 Jun 2012 09:56:21 -0400
Subject: Comcast IPv6 Update
In-Reply-To:
References:
Message-ID:
My understanding is that Comcast only does IPv6 on business customers that are on their "backbone" network, not those on their docsis network.
If you have BGP or fiber with 7922 you should be able to get IPv6.
- Jared
On Jun 1, 2012, at 9:51 AM, Jimmy Sadri wrote:
> Wow... I just wanted some info on deployment scheduling and possilbe
> timelines for getting Ipv6 and I get all that. Gotta say they could really
> do better in the customer service dept. I wonder if you guys have any more
> info on this or can at least point me in the right direction... like I
> said I already tried Comcast Business Support with the above results... so I
> guess if you can help find out this before World Ipv6 day so that I
> could participate that would be ideal... I wonder if anyone else has tried
> getting this info on the list with better results?
From wayne at tuckerlabs.com Fri Jun 1 09:03:25 2012
From: wayne at tuckerlabs.com (Wayne Tucker)
Date: Fri, 1 Jun 2012 07:03:25 -0700
Subject: BGP ORF in practice
In-Reply-To: <18022357-823A-4AA5-94B9-C97B7E7B52D8@rob.sh>
References:
<18022357-823A-4AA5-94B9-C97B7E7B52D8@rob.sh>
Message-ID:
On Thu, May 31, 2012 at 10:59 AM, Rob Shakir wrote:
> It has some potential to be difficult to manage where implementations
> begin to experience complexities in building UPDATE message replication
> groups (where peers have a dynamic advertisement (egress) policy due to ORF,
> then this may mean that the number of peers with common UPDATE policies
> reduces, and hence concepts like policy-driven UPDATE groups become less
> efficient). This may impact the scaling of your BGP speakers in ways that
> are not easy to model - and hence may be undesirable on PE/border devices
> where control-plane CPU is a concern.
Makes sense - ORF would reduce the net amount of processing required,
but puts more of it on the advertising side.
> In an inter-domain context, I have seen some discussion of ORF as a means
> by which an L3VPN customer may choose to receive only a subset of their
> routing information at particular "low feature" sites - but the
> inter-operability issues mentioned above resulted in this not being
> deployed. Do you have a similar deployment case?
My deployment case is as an end user of multiple ISPs. At previous
jobs (at service providers) I got used to the flexibility provided by
multiple full tables, but at this job I don't have the budget for
hardware that's really designed to handle that. Without ORF, my
choices are:
1.) default prefixes only
Way too little control for my taste. I'm stuck either letting it pick
one "best" 0/0 to use or tweaking the config so that I can do ECMP
(which freaks out support staff when their traceroute bounces around).
2.) default + subset (such as customer routes)
Better than #1, but less flexible if I want to steer a prefix anywhere
other than to a service provider which is advertising it to me.
3.) default + full
Flexible in that I can filter what I accept and still rely on the 0/0
prefix for "full" reachability. The control plane on my routers can
handle that many prefixes in memory, but it bogs them down a bit and I
have to be careful of how many prefixes I let into the forwarding
table.
Thanks for the input. It sounds like ORF could be viable, but only if
the service provider is amenable and the equipment is compatible.
:w
From John_Brzozowski at Cable.Comcast.com Fri Jun 1 09:04:54 2012
From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John)
Date: Fri, 1 Jun 2012 14:04:54 +0000
Subject: Comcast IPv6 Update
In-Reply-To:
Message-ID:
Jimmy,
Trust me, I work for Comcast and run the IPv6 program. This has been the
case for nearly 7 years. We can take some of the items below off list.
We have launched IPv6 for residential broadband at this time. Commercial
DOCSIS support is later this year.
We can do two things. Get you a residential trial kit so you can have
IPv6 for W6L and make sure I have your information for when we start
trials for commercial DOCSIS support for IPv6.
John
=========================================
John Jason Brzozowski
Comcast Cable
m) +1-609-377-6594
e) mailto:john_brzozowski at cable.comcast.com
o) +1-484-962-0060
w) http://www.comcast6.net
=========================================
-----Original Message-----
From: Jimmy Sadri
Date: Friday, June 1, 2012 9:51 AM
To: Jason Livingood , "'Blake T.
Pfankuch'" , John Jason Brzozowski
, NANOG
Subject: RE: Comcast IPv6 Update
>Jason,
> I remembered this post and decided to check on the status of this
>for World Ipv6 day coming up in on the 5th of this month and so I called
>Comcast bussiness support... what a nightmare... the first guy told me
>that
>I already have static IP address so why do I need Ipv6 addresses?
>Then he told me that I can still "surf the Internet" with Ipv4 addresses
>and
>I don't need Ipv6 addresses. I asked to speak to someone who
>knows more about the Ipv6 rollout he then told me that there is nothing to
>know. I tried to get him to "escalate it" as you suggested below
>but he refused telling me that a request for Ipv6 addresses is not a valid
>technical reason to escalate. He did offer to let me speak to his
>supervisor. His supervisor wasn't much better. I explained to him how I
>have been following things on comcast6.net and with Ipv6 day coming
>up I thought maybe there had been somekind of forward progress on
>deployment
>and could he at least point me in the right direction for someone
>to talk to about it. He then told me that there is no such person and
>that
>if there was such a person that Comcast's Ipv6 rollout plans and
>locations are proprietary information not to revealed to customers like
>me.
>I referenced NANOG and the below post and was told first that
>how do I know that person is actually a Comcast employee? I guess besides
>the addresses from you guys @cable.comcast.com I don't know for sure
>that you guys are actually Comcast employees I just asume that you are who
>you say you are. For the record I don't doubt that you guys work for
>Comcast but then the supervisor tells me that even IF the people I
>referenced DO work for Comcast that they are in violation of company
>policy
>for speaking in a public forum and claiming to work for Comcast...
>
>Wow... I just wanted some info on deployment scheduling and possilbe
>timelines for getting Ipv6 and I get all that. Gotta say they could
>really
>do better in the customer service dept. I wonder if you guys have any
>more
>info on this or can at least point me in the right direction... like I
>said I already tried Comcast Business Support with the above results...
>so I
>guess if you can help find out this before World Ipv6 day so that I
>could participate that would be ideal... I wonder if anyone else has
>tried
>getting this info on the list with better results?
>
>- Jimmy
>
>-----Original Message-----
>From: Livingood, Jason [mailto:Jason_Livingood at cable.comcast.com]
>Sent: Wednesday, November 09, 2011 8:58 AM
>To: Blake T. Pfankuch; Brzozowski, John; NANOG
>Subject: Re: Comcast IPv6 Update
>
>On 11/9/11 11:54 AM, "Blake T. Pfankuch" wrote:
>
>
>>This appears directed at the Home market. Any word on the Business
>>Class market even as a /128?
>
>Business Class is coming later. It won't hurt to contact the Business
>Class
>sales number and ask about IPv6 (and tell them to escalate it) - it all
>helps get us internal support and buy in. It is definitely on our radar
>though.
>
>- Jason
>
>
From John_Brzozowski at Cable.Comcast.com Fri Jun 1 09:05:47 2012
From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John)
Date: Fri, 1 Jun 2012 14:05:47 +0000
Subject: Comcast IPv6 Update
In-Reply-To:
Message-ID:
Commercial DOCSIS is later this year.
Commercial fiber can be supported now.
John
=========================================
John Jason Brzozowski
Comcast Cable
m) +1-609-377-6594
e) mailto:john_brzozowski at cable.comcast.com
o) +1-484-962-0060
w) http://www.comcast6.net
=========================================
-----Original Message-----
From: Jared Mauch
Date: Friday, June 1, 2012 9:56 AM
To: Jimmy Sadri
Cc: Jason Livingood , "'Blake T.
Pfankuch'" , John Jason Brzozowski
, NANOG
Subject: Re: Comcast IPv6 Update
>My understanding is that Comcast only does IPv6 on business customers
>that are on their "backbone" network, not those on their docsis network.
>
>If you have BGP or fiber with 7922 you should be able to get IPv6.
>
>- Jared
>
>On Jun 1, 2012, at 9:51 AM, Jimmy Sadri wrote:
>
>> Wow... I just wanted some info on deployment scheduling and possilbe
>> timelines for getting Ipv6 and I get all that. Gotta say they could
>>really
>> do better in the customer service dept. I wonder if you guys have any
>>more
>> info on this or can at least point me in the right direction... like I
>> said I already tried Comcast Business Support with the above results...
>>so I
>> guess if you can help find out this before World Ipv6 day so that I
>> could participate that would be ideal... I wonder if anyone else has
>>tried
>> getting this info on the list with better results?
>
From mjl at caida.org Fri Jun 1 12:24:32 2012
From: mjl at caida.org (Matthew Luckie)
Date: Fri, 01 Jun 2012 10:24:32 -0700
Subject: Number of providers
Message-ID: <4FC8FAD0.8080000@caida.org>
Based on feedback we have received at http://as-rank.caida.org/ we are
in the process of updating our AS relationship inference algorithm.
We're interested to know how many providers different ASes have based on
their size. We assume that it changes with size of the AS, e.g. Tier-1
have zero.
We would appreciate it if anyone who is willing to provide us with their
AS number and the number of their providers, would email this
information to mjl at caida.org.
Matthew Luckie
CAIDA.
p.s. It would be great if you could also tell us who your providers are.
From nanog-post at rsuc.gweep.net Fri Jun 1 12:38:42 2012
From: nanog-post at rsuc.gweep.net (Joe Provo)
Date: Fri, 1 Jun 2012 13:38:42 -0400
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <4FC87B04.20200@danysek.cz>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
<088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
<4FC77434.5000306@foobar.org>
<1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
<20120531170646.GA2477@pob.ytti.fi> <4FC87B04.20200@danysek.cz>
Message-ID: <20120601173841.GA47560@gweep.net>
On Fri, Jun 01, 2012 at 10:19:16AM +0200, Daniel Suchy wrote:
> On 05/31/2012 07:06 PM, Saku Ytti wrote:
> > On (2012-05-31 08:46 -0700), David Barak wrote:
> >
> >> On what precisely do you base the idea that a mandatory
> >> transitive attribute of a BGP prefix is a "purely advisory flag
> >> which has no real meaning"? I encourage you to reconsider that
> >> opinion - it's actually a useful attribute, much the way that MED
> >> is a useful attribute. Many providers re-write MED, and apparently
> >> some re-write ORIGIN. Neither of those is "network abuse" - it's
> >> more accurately described as "network routing policy." As has been
> >> stated here before: your network, your rules.
> >
> > When provider rewrites MED, they do it, because they don't want peer to
> > cause them to cold-potato, to which they may have compelling reason.
> > Then some clever people realize they forgot to rewrite origin, working
> > around the implicit agreement you had with them.
> >
>
> You CAN rewrite MED, as stated in RFC 4271, section 5.1.4 - but you
> SHOULD NOT change origin attribute, as stated in section 5.1.1. So, in
> terms of rewriting, MED is not comparable to origin.
>
> I think RFC 4271 (http://tools.ietf.org/html/rfc4271) is very clear
> here. Back to the standard, why condone it's violation? Yes, statement
> about origin is here since January 2006 - older RFC 1771 didn't contain
> similar rule. But 6 years after publishing I think everyone had enough
> time to implement this correctly.
Please remind yourself the standard language from rfc 2119. SHOULD NOT
is not in the same ball park as MUST NOT:
"4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label."
> I still think, that professionals shoult follow RFC and not insert their
> own creativity to places, where's not expected - just because they
> decide that as a "cool" idea. For local routing policy - there're still
> lot of knobs, which can be used internally (typically MED, LOCPREF) to
> enforce expected policy and there's technically no reason to change origin.
You clearly did not read the previous posts involving actual historical
evidence [and apparently ongoing] of remote networks attempting action
at a distance knowing that many overlook this part of the decision tree.
Preventing your company from bleeding money or degrading performance at
whim of remote parties certainly is "cool" but also just good business
and proper network hygiene.
Cheers,
Joe
--
RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG
From danny at danysek.cz Fri Jun 1 13:03:50 2012
From: danny at danysek.cz (Daniel Suchy)
Date: Fri, 01 Jun 2012 20:03:50 +0200
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <20120601173841.GA47560@gweep.net>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
<088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
<4FC77434.5000306@foobar.org>
<1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
<20120531170646.GA2477@pob.ytti.fi> <4FC87B04.20200@danysek.cz>
<20120601173841.GA47560@gweep.net>
Message-ID: <4FC90406.1000606@danysek.cz>
On 06/01/2012 07:38 PM, Joe Provo wrote:
> You clearly did not read the previous posts involving actual historical
> evidence [and apparently ongoing] of remote networks attempting action
> at a distance knowing that many overlook this part of the decision tree.
> Preventing your company from bleeding money or degrading performance at
> whim of remote parties certainly is "cool" but also just good business
> and proper network hygiene.
By overwriting origin field, there's no warranty that someone improves
performance at all - it's just imagination. In extreme cases,
performance can be degraded when someone in the middle plays with origin
field and doesn't know reasons, why originating network uses something
else than IGP origin. In RFC 2119 words, full implications were not
understanded - when this overwriting is done generally.
Also, there must be some historical reason, why origin should not be
rewritten (this changed in January 2006). For internal reasons within
the network operator still haves enough knobs to enforce own policy (by
setting localpref, med on his network).
Daniel
From sethm at rollernet.us Fri Jun 1 13:06:24 2012
From: sethm at rollernet.us (Seth Mattinen)
Date: Fri, 01 Jun 2012 11:06:24 -0700
Subject: Comcast IPv6 Update
In-Reply-To:
References:
Message-ID: <4FC904A0.6010702@rollernet.us>
On 6/1/12 7:04 AM, Brzozowski, John wrote:
> Jimmy,
>
> Trust me, I work for Comcast and run the IPv6 program. This has been the
> case for nearly 7 years. We can take some of the items below off list.
>
> We have launched IPv6 for residential broadband at this time. Commercial
> DOCSIS support is later this year.
>
> We can do two things. Get you a residential trial kit so you can have
> IPv6 for W6L and make sure I have your information for when we start
> trials for commercial DOCSIS support for IPv6.
>
Forgive me if this is a stupid question since I've never been a cable
guy, but what's physical difference between residential and commercial coax?
~Seth
From tdurack at gmail.com Fri Jun 1 13:18:47 2012
From: tdurack at gmail.com (Tim Durack)
Date: Fri, 1 Jun 2012 14:18:47 -0400
Subject: 1310nm optics over Corning LEAF G.655?
Message-ID:
Anyone run 1000BASE-LX/10GBASE-LR 1310nm optics over a ~10km Corning
LEAF G.655 span?
I understand this fiber is not optimized for such usage, but what is
the real-world behaviour? I'm having a hard time finding hard data.
(Normal optics will be 1550nm and DWDM over ~40-100km spans.)
--
Tim:>
From Kevinkarch at vackinc.com Fri Jun 1 13:30:19 2012
From: Kevinkarch at vackinc.com (Kevin L. Karch)
Date: Fri, 1 Jun 2012 13:30:19 -0500
Subject: 1310nm optics over Corning LEAF G.655?
In-Reply-To:
References:
Message-ID: <031001cd4024$994700a0$cbd501e0$@vackinc.com>
Tim
Yes we have built several links with the 1310nm devices on Corning LEAF. One
span distance was 14 KM.
Can we offer you a quote on optics and installation support?
Thanks,
Kevin L. Karch
Network Specialist
Direct: 847-833-8810
Fax: 847-985-5550
Email: kevinkarch at vackinc.com
Web: www.vackinc.com
The Optical Network Specialists
-----Original Message-----
From: Tim Durack [mailto:tdurack at gmail.com]
Sent: Friday, June 01, 2012 1:19 PM
To: nanog at nanog.org
Subject: 1310nm optics over Corning LEAF G.655?
Anyone run 1000BASE-LX/10GBASE-LR 1310nm optics over a ~10km Corning LEAF
G.655 span?
I understand this fiber is not optimized for such usage, but what is the
real-world behaviour? I'm having a hard time finding hard data.
(Normal optics will be 1550nm and DWDM over ~40-100km spans.)
--
Tim:>
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2178 / Virus Database: 2425/5038 - Release Date: 06/01/12
From tdurack at gmail.com Fri Jun 1 13:41:16 2012
From: tdurack at gmail.com (Tim Durack)
Date: Fri, 1 Jun 2012 14:41:16 -0400
Subject: 1310nm optics over Corning LEAF G.655?
In-Reply-To: <031001cd4024$994700a0$cbd501e0$@vackinc.com>
References:
<031001cd4024$994700a0$cbd501e0$@vackinc.com>
Message-ID:
On Fri, Jun 1, 2012 at 2:30 PM, Kevin L. Karch wrote:
> Tim
>
> Yes we have built several links with the 1310nm devices on Corning LEAF. One
> span distance was 14 KM.
>
> Can we offer you a quote on optics and installation support?
That's a kind offer, but we are quite well setup :-) Just looking for
field experience.
14km with standard 1310nm optics? No issues with the cutoff wavelength
being >1310nm? GigE or 10GigE?
--
Tim:>
From rdekema at gmail.com Fri Jun 1 14:06:32 2012
From: rdekema at gmail.com (Rusty Dekema)
Date: Fri, 1 Jun 2012 15:06:32 -0400
Subject: Comcast IPv6 Update
In-Reply-To: <4FC904A0.6010702@rollernet.us>
References:
<4FC904A0.6010702@rollernet.us>
Message-ID:
On Fri, Jun 1, 2012 at 2:06 PM, Seth Mattinen wrote:
> Forgive me if this is a stupid question since I've never been a cable
> guy, but what's physical difference between residential and commercial
> coax?
>
Not much, as far as I can tell. I'm a commercial ("Business Class" in
Comcast's terminology) coax customer; the CPE is just plugged into the
cable outlet in my apartment.
Comcast requires you to use the CPE they supply if you want a static IP up
through a /28 on commercial coax, which is kind of a shame. (Also, a /28
seems to be the largest block they will give you over commercial coax.)
Their CPE announces your address space into Comcast's network with RIPv2,
and presumably they don't wish to share the RIP credentials with small
customers. In the past, the admin ("mso") passwords were the same on all of
their commercial coax CPE so you could tinker if desired, but that is no
longer the case.
Some people have speculated that there are different QAMs (frequencies) for
commercial vs residential customers, but I have not seen any indication
that that is the case.
Finally, there is no 250 GB cap on commercial coax service, for now. (Not
that that's a physical difference.)
-Rusty
From sra+nanog at hactrn.net Fri Jun 1 14:18:09 2012
From: sra+nanog at hactrn.net (Rob Austein)
Date: Fri, 01 Jun 2012 15:18:09 -0400
Subject: rpki vs. secure dns?
In-Reply-To: <4FC5AAEA.103@isc.org>
References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi>
<4FC3F5D7.5000206@isc.org> <20120529102759.GA25838@nic.fr>
<4FC4ACCE.6000903@isc.org>
<6C8F01BD-72C5-4361-B5C8-6603B24B426C@virtualized.org>
<276EF4CD-1710-4F71-8728-894C0433286A@ripe.net>
<5B556145-6859-49F0-BCD4-4E8D316CD828@castlepoint.net>
<4FC5AAEA.103@isc.org>
Message-ID: <20120601191809.4E56A17244@thrintun.hactrn.net>
Another difference between RPKI and ROVER which hasn't come up much:
RPKI incorporates a lot of pre-existing machinery from X.509 et al.
This drags in some tedious detail which makes people's eyes cross, but
it gives us some tools which simply aren't available in DNS at
present. In particular, X.509's CRL mechanism combined with the way
that RPKI uses CMS messages with single-use EE certificates means that
in RPKI we have a way to revoke individual objects (eg, ROAs) at will.
DNSSEC only just barely has revocation at all, and that only for
DNSKEYs. The nearest equivalent to per-object revocation one could do
in DNSSEC would be either:
- generate a new ZSK, re-sign everything in the zone with the new
ZSK except for the RRsets you want to get rid of, and revoke the
old ZSK, or
- keep as many distinct ZSKs in the zone as you intend to have
distinctly revocable groups of objects in the zone, and make sure
you sign the right objects with the right ZSKs.
Neither of these solutions is very good: the first may involve
re-signing a lot of data every time you change anything, while the
latter is complex and tends to bloat the zone's apex DNSKEY RRset.
I suppose a third option would be to make every DNS owner name in the
reverse tree be a separate zone. Doesn't seem like an improvement.
Summarizing a few other things other people have mentioned:
- The normal operating mode with RPKI is to fetch everything rather
than do a point query. We've spent the last decade or so making
that harder to do with DNS (blocking AXFR/IXFR, using NSEC3 instead
of NSEC, etc). This makes it fairly difficult to know in advance
what queries one should be asking ROVER (as Paul Vixie puts it,
ROVER isn't a catalogue). When I pressed the ROVER folks about this
at the Paris IETF meeting, they mumbled something about maybe
walking the IRR or other external databases as a way of knowing what
DNS queries to issue.
- Circular dependencies are a problem. Helical dependencies can be
made to work, but this says that one probably should not be
depending on routing to make a point query to make decisions about
routing. If you look at the architecture of the existing RPKI
validators (well, mine and BBN's, anyway, not sure about RIPE's but
suspect they took the same approach), we've gone to some trouble to
make sure that the validator will continue to work across network
outages as long as the collected data haven't expired or been
revoked. In theory one could do the same thing with bulk transfers
of DNS (whether AXFR/IXFR or NSEC walking, if they worked) but it
would not work well with point queries.
- ROVER gives us no traction on path validation (BGPSEC), it's limited
to origin validation. RPKI can certify both prefixes and ASNs,
which gives it the basics needed to support path validation as well
as origin validation. ASNs have no hierarchical structure, thus
would be a very poor match for encoding as DNS names.
- Some of the DNS aspects of ROVER are a little strange. In
particular, as currently specified ROVER requires the relying party
to pay attention to DNS zone cuts, which is not normal in DNS (the
basic DNS model since RFC 883 has been that zones are something for
the zone administrator to worry about, resolvers mostly just see a
tree of RRsets). ROVER requires the relying party to check for the
same data in multiple zones and pay close attention to zone cuts.
While it is certainly possible to do all this, it is not a matter of
issuing a simple DNS query and you're done. DNS caching effects can
also complicate matters here if the zone structure is changing:
think about what happens if you have cached responses to some (but
not all) of the queries you need to make to figure out whether to
allow a more specific route punched out of a larger prefix block.
- The reuse of existing infrastructure argument for ROVER is somewhat
disingenuous -- it's only partial reuse of existing infrastructure.
ROVER's new encoding of prefixes as DNS names means that a lot of
new stuff would need to be deployed, and attempting to be backwards
compatible with the existing DNS reverse tree adds some complexity
to ROVER's architecture (conflicting data for same prefix can appear
in multiple zones, relying party has to sort this out, yum).
As far as I can tell, ROVER doesn't solve any of the hard problems in
RPKI. It's a different encoding of a partial subset of the data, with
some of the features removed.
From jared at puck.nether.net Fri Jun 1 14:21:18 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Fri, 1 Jun 2012 15:21:18 -0400
Subject: Comcast IPv6 Update
In-Reply-To: <4FC904A0.6010702@rollernet.us>
References:
<4FC904A0.6010702@rollernet.us>
Message-ID: <20120601192118.GC3335@puck.nether.net>
On Fri, Jun 01, 2012 at 11:06:24AM -0700, Seth Mattinen wrote:
> On 6/1/12 7:04 AM, Brzozowski, John wrote:
> > Jimmy,
> >
> > Trust me, I work for Comcast and run the IPv6 program. This has been the
> > case for nearly 7 years. We can take some of the items below off list.
> >
> > We have launched IPv6 for residential broadband at this time. Commercial
> > DOCSIS support is later this year.
> >
> > We can do two things. Get you a residential trial kit so you can have
> > IPv6 for W6L and make sure I have your information for when we start
> > trials for commercial DOCSIS support for IPv6.
> >
>
>
> Forgive me if this is a stupid question since I've never been a cable
> guy, but what's physical difference between residential and commercial coax?
Usually these are terminated on a different CMTS and may use different
frequencies allocated.
From a business side, there is a higher SLA afforded to the users,
including phone notification of planned outages, etc that would happen.
- Jared
--
Jared Mauch | pgp key available via finger from jared at puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only mine.
From jimb at jsbc.cc Fri Jun 1 14:25:54 2012
From: jimb at jsbc.cc (Jim Burwell)
Date: Fri, 01 Jun 2012 12:25:54 -0700
Subject: Comcast IPv6 Update
In-Reply-To: <4FC904A0.6010702@rollernet.us>
References:
<4FC904A0.6010702@rollernet.us>
Message-ID: <4FC91742.704@jsbc.cc>
On 6/1/2012 11:06, Seth Mattinen wrote:
> On 6/1/12 7:04 AM, Brzozowski, John wrote:
>> Jimmy,
>>
>> Trust me, I work for Comcast and run the IPv6 program. This has been the
>> case for nearly 7 years. We can take some of the items below off list.
>>
>> We have launched IPv6 for residential broadband at this time. Commercial
>> DOCSIS support is later this year.
>>
>> We can do two things. Get you a residential trial kit so you can have
>> IPv6 for W6L and make sure I have your information for when we start
>> trials for commercial DOCSIS support for IPv6.
>>
>
> Forgive me if this is a stupid question since I've never been a cable
> guy, but what's physical difference between residential and commercial coax?
>
> ~Seth
>
I'm a Comcast biz customer, mostly so I can have static IPs.
I believe the main differences are that biz class has a different group
of people supporting it and provisioning it. They also use different
CPE. Probably also use different VLANs and such past the head end. But
for biz class customers on cable, it uses the same underlying
infrastructure as residential.
I'm mostly speculating here, but I'd think a big hurdle for getting IPv6
service on biz class is in coming up with the
support/provisioning/logistics infrastructure to support biz customers
with IPv6. The residential customers have less control over the CPE
than business class, likely making it easier for comcast to make changes
for residential service. Comcast can update the CPE image, start
running DHCPv6, and voila. But biz customers routers are somewhat
configurable, and many biz class customers run their own
routers/firewalls behind the comcast CPE (as do some residential
customers also, of course), likely making things more complicated. I'd
speculate that all the technical pieces are there to do it, but the
logistical/support/management pieces probably aren't ready yet.
Obviously, only the Comcast guys on here (John and Jason) know the whole
story. But I'm patiently waiting for my native v6! It'll happen
eventually. :-)
From jimb at jsbc.cc Fri Jun 1 14:28:09 2012
From: jimb at jsbc.cc (Jim Burwell)
Date: Fri, 01 Jun 2012 12:28:09 -0700
Subject: Comcast IPv6 Update
In-Reply-To: <20120601192118.GC3335@puck.nether.net>
References:
<4FC904A0.6010702@rollernet.us> <20120601192118.GC3335@puck.nether.net>
Message-ID: <4FC917C9.5000905@jsbc.cc>
On 6/1/2012 12:21, Jared Mauch wrote:
> On Fri, Jun 01, 2012 at 11:06:24AM -0700, Seth Mattinen wrote:
>> On 6/1/12 7:04 AM, Brzozowski, John wrote:
>>> Jimmy,
>>>
>>> Trust me, I work for Comcast and run the IPv6 program. This has been the
>>> case for nearly 7 years. We can take some of the items below off list.
>>>
>>> We have launched IPv6 for residential broadband at this time. Commercial
>>> DOCSIS support is later this year.
>>>
>>> We can do two things. Get you a residential trial kit so you can have
>>> IPv6 for W6L and make sure I have your information for when we start
>>> trials for commercial DOCSIS support for IPv6.
>>>
>>
>> Forgive me if this is a stupid question since I've never been a cable
>> guy, but what's physical difference between residential and commercial coax?
> Usually these are terminated on a different CMTS and may use different
> frequencies allocated.
>
> From a business side, there is a higher SLA afforded to the users,
> including phone notification of planned outages, etc that would happen.
>
> - Jared
>
Ah I didn't know they even used separate CMTS for the biz customers.
From joly at punkcast.com Fri Jun 1 15:48:40 2012
From: joly at punkcast.com (Joly MacFie)
Date: Fri, 1 Jun 2012 16:48:40 -0400
Subject: NYC World IPv6 Launch event
Message-ID:
As for IPv6 Day last year, when it went amazingly well, ISOC-NY is
organizing a chat + booze-up to mark the IPv6 Launch next Wednesday Jun 6
2012. Hopefully by 7pm initial kinks will have been well ironed out and
everyone will be free to attend..
*What*: World IPv6 Launch Discussion and Celebration.
*When*: Wed. June 6, 2012 - 7pm-8.30pm
*Where*: Courant Institute NYU, Rm 201, 251 Mercer St. NYC
*Who*: Free. Public welcome, especially network admins!
*Hashtags*: #v6launch ;
#ipv6
*RSVP*: email
| facebook |
meetup
More info: http://isoc-ny.org/p2/?p=3526
--
---------------------------------------------------------------
Joly MacFie 218 565 9365 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
http://pinstand.com - http://punkcast.com
VP (Admin) - ISOC-NY - http://isoc-ny.org
--------------------------------------------------------------
-
From cidr-report at potaroo.net Fri Jun 1 17:00:02 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 1 Jun 2012 22:00:02 GMT
Subject: BGP Update Report
Message-ID: <201206012200.q51M02QN055688@wattle.apnic.net>
BGP Update Report
Interval: 24-May-12 -to- 31-May-12 (7 days)
Observation Point: BGP Peering with AS131072
TOP 20 Unstable Origin AS
Rank ASN Upds % Upds/Pfx AS-Name
1 - AS383 192192 8.5% 1779.6 -- AFCONC-BLOCK1-AS - 754th Electronic Systems Group
2 - AS8452 91007 4.0% 89.9 -- TE-AS TE-AS
3 - AS8402 60332 2.6% 47.7 -- CORBINA-AS OJSC "Vimpelcom"
4 - AS9829 54914 2.4% 62.4 -- BSNL-NIB National Internet Backbone
5 - AS19647 47156 2.1% 9431.2 -- HPOD20001 - Hewlett-Packard Operation Division
6 - AS38142 33384 1.5% 2086.5 -- UNAIR-AS-ID Universitas Airlangga
7 - AS12479 27393 1.2% 351.2 -- UNI2-AS France Telecom Espana SA
8 - AS35994 26629 1.2% 951.0 -- AKAMAI-AS - Akamai Technologies, Inc.
9 - AS7908 25800 1.1% 344.0 -- Comsat Argentina S.A.
10 - AS5800 23102 1.0% 86.2 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
11 - AS41661 21899 1.0% 61.7 -- ERTH-CHEL-AS CJSC "ER-Telecom Holding"
12 - AS1257 20680 0.9% 108.8 -- TELE2
13 - AS13118 20040 0.9% 417.5 -- ASN-YARTELECOM OJSC Rostelecom
14 - AS28306 19103 0.8% 2122.6 -- TC Net Inform?tica e Telecomunica??es LTDA
15 - AS10455 18155 0.8% 2017.2 -- LUCENT-CIO - Lucent Technologies Inc.
16 - AS17813 17513 0.8% 142.4 -- MTNL-AP Mahanagar Telephone Nigam Ltd.
17 - AS3549 16826 0.7% 168.3 -- GBLX Global Crossing Ltd.
18 - AS36856 16593 0.7% 8296.5 -- MOZILLA-CORP - Mozilla Corporation
19 - AS25543 15053 0.7% 273.7 -- FasoNet-AS
20 - AS24560 13716 0.6% 19.8 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN Upds % Upds/Pfx AS-Name
1 - AS19647 47156 2.1% 9431.2 -- HPOD20001 - Hewlett-Packard Operation Division
2 - AS36856 16593 0.7% 8296.5 -- MOZILLA-CORP - Mozilla Corporation
3 - AS44798 7750 0.3% 7750.0 -- PERVOMAYSK-AS PP "SKS-Pervomaysk"
4 - AS3 2638 0.1% 683.0 -- PRED-AS PRED-Telecom OOO
5 - AS32528 12095 0.5% 2419.0 -- ABBOTT Abbot Labs
6 - AS28306 19103 0.8% 2122.6 -- TC Net Inform?tica e Telecomunica??es LTDA
7 - AS38142 33384 1.5% 2086.5 -- UNAIR-AS-ID Universitas Airlangga
8 - AS10455 18155 0.8% 2017.2 -- LUCENT-CIO - Lucent Technologies Inc.
9 - AS383 192192 8.5% 1779.6 -- AFCONC-BLOCK1-AS - 754th Electronic Systems Group
10 - AS55665 1043 0.1% 1043.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia
11 - AS35994 26629 1.2% 951.0 -- AKAMAI-AS - Akamai Technologies, Inc.
12 - AS29126 918 0.0% 918.0 -- DATIQ-AS Datiq B.V.
13 - AS16535 890 0.0% 890.0 -- ECHOS-3 - Echostar Holding Purchasing Corporation
14 - AS19318 12159 0.5% 715.2 -- NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
15 - AS53531 672 0.0% 672.0 -- MIDWEST-CARECENTER - Midwest Palliative & Hospice CareCenter
16 - AS38857 950 0.0% 475.0 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd.
17 - AS56616 451 0.0% 451.0 -- SHARIF-AS Tarahan Shabake Sharif LTD
18 - AS25821 450 0.0% 450.0 -- NET-SCNB - Suffolk County National Bank
19 - AS29512 2199 0.1% 439.8 -- TVK-WROC-AS TVK Tel-Ka Wroclaw
20 - AS48068 435 0.0% 435.0 -- VISONIC Visonic Ltd
TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
1 - 109.161.64.0/19 19671 0.8% AS13118 -- ASN-YARTELECOM OJSC Rostelecom
2 - 63.245.221.0/24 16573 0.7% AS36856 -- MOZILLA-CORP - Mozilla Corporation
3 - 168.87.176.0/24 14222 0.6% AS19647 -- HPOD20001 - Hewlett-Packard Operation Division
4 - 168.87.128.0/21 14171 0.6% AS19647 -- HPOD20001 - Hewlett-Packard Operation Division
5 - 130.36.34.0/24 10737 0.4% AS32528 -- ABBOTT Abbot Labs
6 - 69.31.106.0/23 9520 0.4% AS35994 -- AKAMAI-AS - Akamai Technologies, Inc.
7 - 155.72.152.0/21 9383 0.4% AS19647 -- HPOD20001 - Hewlett-Packard Operation Division
8 - 155.72.158.0/24 9376 0.4% AS19647 -- HPOD20001 - Hewlett-Packard Operation Division
9 - 41.43.147.0/24 9035 0.4% AS8452 -- TE-AS TE-AS
10 - 23.2.6.0/23 8522 0.3% AS35994 -- AKAMAI-AS - Akamai Technologies, Inc.
11 - 23.65.27.0/24 8520 0.3% AS35994 -- AKAMAI-AS - Akamai Technologies, Inc.
12 - 62.36.252.0/22 8022 0.3% AS12479 -- UNI2-AS France Telecom Espana SA
13 - 91.202.212.0/22 7750 0.3% AS44798 -- PERVOMAYSK-AS PP "SKS-Pervomaysk"
14 - 62.36.249.0/24 6535 0.3% AS12479 -- UNI2-AS France Telecom Espana SA
15 - 62.36.241.0/24 6218 0.2% AS12479 -- UNI2-AS France Telecom Espana SA
16 - 62.36.210.0/24 6060 0.2% AS12479 -- UNI2-AS France Telecom Espana SA
17 - 59.177.48.0/20 5860 0.2% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd.
18 - 194.63.9.0/24 4646 0.2% AS1273 -- CW Cable and Wireless Worldwide plc
19 - 182.64.0.0/16 4607 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
20 - 192.11.177.0/24 3616 0.1% AS10455 -- LUCENT-CIO - Lucent Technologies Inc.
Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
nanog at nanog.org
eof-list at ripe.net
apops at apops.net
routing-wg at ripe.net
afnog at afnog.org
From cidr-report at potaroo.net Fri Jun 1 17:00:00 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 1 Jun 2012 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201206012200.q51M00hr055681@wattle.apnic.net>
This report has been generated at Fri Jun 1 21:12:54 2012 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date Prefixes CIDR Agg
25-05-12 414357 242094
26-05-12 414444 242009
27-05-12 414372 242171
28-05-12 414483 242396
29-05-12 414855 242346
30-05-12 415000 242304
31-05-12 414797 242308
01-06-12 415005 242253
AS Summary
41293 Number of ASes in routing system
17231 Number of ASes announcing only one prefix
3411 Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
112706016 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 01Jun12 ---
ASnum NetsNow NetsAggr NetGain % Gain Description
Table 415012 242341 172671 41.6% All ASes
AS6389 3411 196 3215 94.3% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS7029 3353 1843 1510 45.0% WINDSTREAM - Windstream
Communications Inc
AS22773 1638 135 1503 91.8% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS4766 2643 1176 1467 55.5% KIXS-AS-KR Korea Telecom
AS18566 2092 706 1386 66.3% COVAD - Covad Communications
Co.
AS28573 1896 521 1375 72.5% NET Servicos de Comunicao S.A.
AS2118 1301 14 1287 98.9% RELCOM-AS OOO "NPO Relcom"
AS4323 1575 387 1188 75.4% TWTC - tw telecom holdings,
inc.
AS10620 1926 760 1166 60.5% Telmex Colombia S.A.
AS1785 1912 806 1106 57.8% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS4755 1577 542 1035 65.6% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS7303 1435 448 987 68.8% Telecom Argentina S.A.
AS7552 1097 188 909 82.9% VIETEL-AS-AP Vietel
Corporation
AS26615 901 32 869 96.4% Tim Celular S.A.
AS8151 1490 684 806 54.1% Uninet S.A. de C.V.
AS18101 948 159 789 83.2% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI
AS17974 1927 1161 766 39.8% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia
AS4808 1105 349 756 68.4% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS9394 839 159 680 81.0% CRNET CHINA RAILWAY
Internet(CRNET)
AS13977 772 122 650 84.2% CTELCO - FAIRPOINT
COMMUNICATIONS, INC.
AS3356 1099 463 636 57.9% LEVEL3 Level 3 Communications
AS30036 1420 792 628 44.2% MEDIACOM-ENTERPRISE-BUSINESS -
Mediacom Communications Corp
AS17676 692 75 617 89.2% GIGAINFRA Softbank BB Corp.
AS22561 1020 419 601 58.9% DIGITAL-TELEPORT - Digital
Teleport Inc.
AS19262 997 398 599 60.1% VZGNI-TRANSIT - Verizon Online
LLC
AS8452 1369 779 590 43.1% TE-AS TE-AS
AS24560 1027 447 580 56.5% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS3549 1002 443 559 55.8% GBLX Global Crossing Ltd.
AS22047 583 31 552 94.7% VTR BANDA ANCHA S.A.
AS4780 831 283 548 65.9% SEEDNET Digital United Inc.
Total 43878 14518 29360 66.9% Top 30 total
Possible Bogus Routes
10.86.64.32/30 AS65530 -Private Use AS-
10.86.64.36/30 AS65530 -Private Use AS-
10.86.65.32/30 AS65530 -Private Use AS-
10.86.65.36/30 AS65530 -Private Use AS-
10.255.255.0/30 AS65530 -Private Use AS-
10.255.255.4/30 AS65530 -Private Use AS-
10.255.255.8/30 AS65530 -Private Use AS-
14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd.
41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited
62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV
62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV
66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION
66.207.32.0/20 AS23011
66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications
69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A.
72.44.16.0/20 AS15054 HAMELTRONICS - Hameltronics, LLC
74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC
74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC
74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC
74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC
74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC
74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC
74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC
74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC
74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC
74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC
74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC
74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC
74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC
74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC
74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC
74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC
98.159.96.0/20 AS46975
100.100.0.0/16 AS9198 KAZTELECOM-AS JSC Kazakhtelecom
110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A.
116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network
116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network
116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network
117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
120.136.17.0/24 AS38779 BMG-AS-ID Badan Meteorologi dan Geofisika
121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street
142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP
172.45.1.0/24 AS3356 LEVEL3 Level 3 Communications
172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group)
172.223.60.0/22 AS6910 DIALTELECOMRO Dial Telecom S.R.L.
194.33.112.0/23 AS12859 NL-BIT BIT BV
200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC.
200.6.49.0/24 AS23148 TERREMARK Terremark
200.24.73.0/24 AS26061 Equant Colombia
200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V.
200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey
200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda
200.58.248.0/21 AS27849
200.75.184.0/21 AS14754 Telgua
200.106.128.0/20 AS3257 TINET-BACKBONE Tinet SpA
200.115.112.0/20 AS3257 TINET-BACKBONE Tinet SpA
202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
202.58.113.0/24 AS19161
202.83.120.0/21 AS37972
202.83.124.0/24 AS37972
202.83.125.0/24 AS37972
202.83.126.0/24 AS37972
202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
202.122.134.0/24 AS38615
202.140.128.0/19 AS9583 SIFY-AS-IN Sify Limited
202.160.152.0/22 AS10113 EFTEL-AS-AP Eftel Limited.
202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd.
202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia
202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited
203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications
203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications
203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications
203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications
203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications
203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications
203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd
203.142.219.0/24 AS45149
205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A.
206.123.129.0/24 AS10790 INREACH-AS - InReach Internet
206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
207.174.131.0/24 AS26116 INDRA - Indra's Net Inc
207.174.132.0/23 AS26116 INDRA - Indra's Net Inc
207.174.152.0/23 AS26116 INDRA - Indra's Net Inc
207.174.154.0/24 AS26116 INDRA - Indra's Net Inc
207.174.155.0/24 AS26116 INDRA - Indra's Net Inc
207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc.
207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC
207.231.96.0/19 AS11194 NUNETPA - NuNet Inc.
208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC
208.91.56.0/21 AS22241 IC2NET - IC2NET
208.91.56.0/24 AS22241 IC2NET - IC2NET
208.91.57.0/24 AS22241 IC2NET - IC2NET
208.91.58.0/24 AS22241 IC2NET - IC2NET
208.91.59.0/24 AS22241 IC2NET - IC2NET
208.91.60.0/24 AS22241 IC2NET - IC2NET
208.91.61.0/24 AS22241 IC2NET - IC2NET
208.91.62.0/24 AS22241 IC2NET - IC2NET
208.91.63.0/24 AS22241 IC2NET - IC2NET
209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications
209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network
209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC
216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc.
216.21.160.0/20 AS27876 American Data Networks
216.194.160.0/20 AS27876 American Data Networks
Please see http://www.cidr-report.org for the full report
------------------------------------
Copies of this report are mailed to:
nanog at nanog.org
eof-list at ripe.net
apops at apops.net
routing-wg at ripe.net
afnog at afnog.org
From ras at e-gerbil.net Fri Jun 1 19:42:57 2012
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Fri, 1 Jun 2012 19:42:57 -0500
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <4FC90406.1000606@danysek.cz>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
<088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
<4FC77434.5000306@foobar.org>
<1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
<20120531170646.GA2477@pob.ytti.fi> <4FC87B04.20200@danysek.cz>
<20120601173841.GA47560@gweep.net> <4FC90406.1000606@danysek.cz>
Message-ID: <20120602004256.GB66560@gerbil.cluepon.net>
On Fri, Jun 01, 2012 at 08:03:50PM +0200, Daniel Suchy wrote:
>
> By overwriting origin field, there's no warranty that someone improves
> performance at all - it's just imagination. In extreme cases,
> performance can be degraded when someone in the middle plays with
> origin field and doesn't know reasons, why originating network uses
> something else than IGP origin. In RFC 2119 words, full implications
> were not understanded - when this overwriting is done generally.
Uh, what part of "to prevent remote networks from improperly forcing a
cold potato routing behavior on you" sounds imaginary?
> Also, there must be some historical reason, why origin should not be
> rewritten (this changed in January 2006). For internal reasons within
> the network operator still haves enough knobs to enforce own policy
> (by setting localpref, med on his network).
Not really, no. Not every RFC is 100% correct, and they're often written
by people who are not operators (because operators are too busy running
real networks :P). Besides, "SHOULD NOT" means "you probably don't want
to do this, unless you have a really good reason", and enforcing such an
important point in a peering policy is a pretty good reason.
You also clearly don't understand the practical use of localpref. When
you're trying to implement a simple and relatively common policy like
"closest exit routing to a peer with multiple exits", you set the
localprefs the same (localpref is usually used to determine WHICH peer
you'll be sending to), you set the MEDs the same (if you don't want to
artifically select which EXIT to use), AS-PATH lengths are obviously the
same if you have multiple exits, and then the next one down is origin
code. If you can't reset origin code, you run the risk of a remote
network being able to force your network to do something you probably
don't want to do (or at least probably wouldn't want to do, if you had
any idea what you were doing :P).
Please see the previous commentary from Joe Provo, Saku Ytti, etc, they
are quite correct.
--
Richard A Steenbergen http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
From nanog-post at rsuc.gweep.net Fri Jun 1 19:53:37 2012
From: nanog-post at rsuc.gweep.net (Joe Provo)
Date: Fri, 1 Jun 2012 20:53:37 -0400
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <4FC90406.1000606@danysek.cz>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
<088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
<4FC77434.5000306@foobar.org>
<1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
<20120531170646.GA2477@pob.ytti.fi> <4FC87B04.20200@danysek.cz>
<20120601173841.GA47560@gweep.net> <4FC90406.1000606@danysek.cz>
Message-ID: <20120602005336.GA7394@gweep.net>
On Fri, Jun 01, 2012 at 08:03:50PM +0200, Daniel Suchy wrote:
> On 06/01/2012 07:38 PM, Joe Provo wrote:
> > You clearly did not read the previous posts involving actual historical
> > evidence [and apparently ongoing] of remote networks attempting action
> > at a distance knowing that many overlook this part of the decision tree.
> > Preventing your company from bleeding money or degrading performance at
> > whim of remote parties certainly is "cool" but also just good business
> > and proper network hygiene.
>
> By overwriting origin field, there's no warranty that someone improves
> performance at all - it's just imagination.
Cost and performance were merely two reasons someone may wish to prevent
remote parties from using origin to influence outbound traffic from my
network. I can state it is not imagination when I encountered networks
doing this in the past for prefixes they were sourcing. To be clear -
these were prefixes being sourced by a neighbor who was providing
different origin codes on different sessions. Either they were [to
Nick Hilliard's point] using different kit and unaware of the differnt
implementations or [as evidence bore out] purposefully shifting traffic
without arrangement on links that were worse for me and in violation
of the agreement we entered into when peering.
> In extreme cases,
> performance can be degraded when someone in the middle plays with origin
> field and doesn't know reasons, why originating network uses something
> else than IGP origin.
The issues that were repeatedly mentioned were not not 'use something
other than origin IGP'. Rather, two clear examples were:
- a party in the middle adjusting prefixes not of their origin with
the express intent of attracting traffic [from paying downstreams]
- a directly connected party cost-shifting long-haul carriage for their
sourced prefixes without prior arrangement
> In RFC 2119 words, full implications were not
> understanded - when this overwriting is done generally.
I think you're trying to make sense here but it isn't coming through.
You are saying that dealing with someone shifting costs to my network
*after8 asking them what they were doing and getting no useful reply
is not thinking it through?
> Also, there must be some historical reason, why origin should not be
> rewritten (this changed in January 2006). For internal reasons within
> the network operator still haves enough knobs to enforce own policy (by
> setting localpref, med on his network).
There certainly were historical reasons for treating origin as sacrosanct.
Time has marched on and those reasons are now *historical*, hence the
quite reasonable updat eto the RFC. You seem to fail to understand that
MED comes after origin on the decision tree, and therefore someone can
influence traffic carriage without agreement.
Cheers,
Joe
--
RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG
From danny at danysek.cz Sat Jun 2 02:03:24 2012
From: danny at danysek.cz (Daniel Suchy)
Date: Sat, 02 Jun 2012 09:03:24 +0200
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <20120602004256.GB66560@gerbil.cluepon.net>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
<088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
<4FC77434.5000306@foobar.org>
<1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
<20120531170646.GA2477@pob.ytti.fi> <4FC87B04.20200@danysek.cz>
<20120601173841.GA47560@gweep.net> <4FC90406.1000606@danysek.cz>
<20120602004256.GB66560@gerbil.cluepon.net>
Message-ID: <4FC9BABC.9090107@danysek.cz>
On 06/02/2012 02:42 AM, Richard A Steenbergen wrote:
> On Fri, Jun 01, 2012 at 08:03:50PM +0200, Daniel Suchy wrote:
>> By overwriting origin field, there's no warranty that someone improves
>> performance at all - it's just imagination. In extreme cases,
>> performance can be degraded when someone in the middle plays with
>> origin field and doesn't know reasons, why originating network uses
>> something else than IGP origin. In RFC 2119 words, full implications
>> were not understanded - when this overwriting is done generally.
>
> Uh, what part of "to prevent remote networks from improperly forcing a
> cold potato routing behavior on you" sounds imaginary?
It depends, not everything looking as proper from single network
operator in the middle can be proper in end-to-end user experience,
where multiple networks are traversed.
>> Also, there must be some historical reason, why origin should not be
>> rewritten (this changed in January 2006). For internal reasons within
>> the network operator still haves enough knobs to enforce own policy
>> (by setting localpref, med on his network).
>
> Not really, no. Not every RFC is 100% correct, and they're often written
> by people who are not operators (because operators are too busy running
> real networks :P). Besides, "SHOULD NOT" means "you probably don't want
> to do this, unless you have a really good reason", and enforcing such an
> important point in a peering policy is a pretty good reason.
If someone comes with some implementation overwriting ASPATH (even it
may not) and excuses this by RFC incorrectness from his perspective,
you'll understand it? Probably not. It's relative.
> You also clearly don't understand the practical use of localpref. When
> you're trying to implement a simple and relatively common policy like
> "closest exit routing to a peer with multiple exits", you set the
> localprefs the same (localpref is usually used to determine WHICH peer
> you'll be sending to), you set the MEDs the same (if you don't want to
> artifically select which EXIT to use), AS-PATH lengths are obviously the
> same if you have multiple exits, and then the next one down is origin
> code. If you can't reset origin code, you run the risk of a remote
> network being able to force your network to do something you probably
> don't want to do (or at least probably wouldn't want to do, if you had
> any idea what you were doing :P).
Well, this matches situatios, where two networks have more than single
interconnection and still for prefixes originated from that particular
network. But when there's only one interconnection, there's no such
reason. Intermediate networks, even having multiple peers will probably
see similar origin on all their peers.
> Please see the previous commentary from Joe Provo, Saku Ytti, etc, they
> are quite correct.
I don't think they admits all consequences. When some knob (origin) is
not disabled by policy for single prefix visible at multiple points,
some "creative" operators should come with other methods to achieve what
they wants. Prefix deagregation is first thing, that comes to mind. Even
they'll also slightly violate RFC (having not single policy - well, they
assume RFC is not correct), they simply start to announce deagregated
prefixes next to aggregate one. But deaggregated prefixes are announced
only to specific peers - and yes, this works. Then, you can have any
policy, have everything normalized at all peers - but most specific
prefix in your table visible over particular path simply wins over
everything. And this is not a imaginary case - this is clearly visible
in real routing table - 41% of address space (in IPv4) is deaggreated,
in my experience mainly due to "traffic engineering" purposes - smaller
end networks are simply enforced to do this, and some people here
confirmed this in this discussion...
- Daniel
From danny at danysek.cz Sat Jun 2 02:27:36 2012
From: danny at danysek.cz (Daniel Suchy)
Date: Sat, 02 Jun 2012 09:27:36 +0200
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <20120602005336.GA7394@gweep.net>
References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org>
<088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
<4FC77434.5000306@foobar.org>
<1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
<20120531170646.GA2477@pob.ytti.fi> <4FC87B04.20200@danysek.cz>
<20120601173841.GA47560@gweep.net> <4FC90406.1000606@danysek.cz>
<20120602005336.GA7394@gweep.net>
Message-ID: <4FC9C068.2070506@danysek.cz>
On 06/02/2012 02:53 AM, Joe Provo wrote:
> Cost and performance were merely two reasons someone may wish to prevent
> remote parties from using origin to influence outbound traffic from my
> network.
As I mentioned already, it will influence that by another way. And this
costs *you* more money - you have to pay for router with larger TCAMs,
more memory, faster CPUs... and yes, deaggregation is very simple task
for originating network - much easier than playing with the origin flag,
which is not understanded widely.
> I can state it is not imagination when I encountered networks
> doing this in the past for prefixes they were sourcing. To be clear -
> these were prefixes being sourced by a neighbor who was providing
> different origin codes on different sessions. Either they were [to
> Nick Hilliard's point] using different kit and unaware of the differnt
> implementations or [as evidence bore out] purposefully shifting traffic
> without arrangement on links that were worse for me and in violation
> of the agreement we entered into when peering.
More specific prefix in addition to aggregate one visible only over
specific peers will do the job, too. And will do that job better... but
for what cost (not only to you)...?
> There certainly were historical reasons for treating origin as sacrosanct.
> Time has marched on and those reasons are now *historical*, hence the
> quite reasonable updat eto the RFC. You seem to fail to understand that
> MED comes after origin on the decision tree, and therefore someone can
> influence traffic carriage without agreement.
You seem to fail realize other (easier) ways to influence traffic
carriage. Deaggregation with selective route announcement is quite
common way, many networks do that.
- Daniel
From nanog-post at rsuc.gweep.net Sat Jun 2 05:43:15 2012
From: nanog-post at rsuc.gweep.net (Joe Provo)
Date: Sat, 2 Jun 2012 06:43:15 -0400
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <4FC9C068.2070506@danysek.cz>
References: <4FC75565.4000404@foobar.org>
<088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
<4FC77434.5000306@foobar.org>
<1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
<20120531170646.GA2477@pob.ytti.fi> <4FC87B04.20200@danysek.cz>
<20120601173841.GA47560@gweep.net> <4FC90406.1000606@danysek.cz>
<20120602005336.GA7394@gweep.net> <4FC9C068.2070506@danysek.cz>
Message-ID: <20120602104315.GA23204@gweep.net>
Last post on this topic for me. You seem to wish to argue
against the lessons of history and the reality of running
a network on the global Internet.
On Sat, Jun 02, 2012 at 09:27:36AM +0200, Daniel Suchy wrote:
> On 06/02/2012 02:53 AM, Joe Provo wrote:
> > Cost and performance were merely two reasons someone may wish to prevent
> > remote parties from using origin to influence outbound traffic from my
> > network.
> As I mentioned already, it will influence that by another way. And this
> costs *you* more money - you have to pay for router with larger TCAMs,
> more memory, faster CPUs... and yes, deaggregation is very simple task
> for originating network - much easier than playing with the origin flag,
> which is not understanded widely.
The two issues are orthogonal. Deaggregating sources have
been cost-shifting [in a highly visible and easily examined
and often trivially-filtered] manner for ages. There is no
data to support the premis that touching origin creates more
of this behavior and plenty to refute it. Deaggregation
preexists and was always a problem with which one had to
deal as supposed "needed TE" by those too cheap to build a
proper network sadly became more acceptable over time.
A midspan network deaggregating someone else's prefixes is
broken and gets called out, generally by the originator if
they have a clue.
> > I can state it is not imagination when I encountered networks
> > doing this in the past for prefixes they were sourcing. To be clear -
> > these were prefixes being sourced by a neighbor who was providing
> > different origin codes on different sessions. Either they were [to
> > Nick Hilliard's point] using different kit and unaware of the differnt
> > implementations or [as evidence bore out] purposefully shifting traffic
> > without arrangement on links that were worse for me and in violation
> > of the agreement we entered into when peering.
>
> More specific prefix in addition to aggregate one visible only over
> specific peers will do the job, too. And will do that job better... but
> for what cost (not only to you)...?
See above.
> > There certainly were historical reasons for treating origin as sacrosanct.
> > Time has marched on and those reasons are now *historical*, hence the
> > quite reasonable updat eto the RFC. You seem to fail to understand that
> > MED comes after origin on the decision tree, and therefore someone can
> > influence traffic carriage without agreement.
>
> You seem to fail realize other (easier) ways to influence traffic
> carriage. Deaggregation with selective route announcement is quite
> common way, many networks do that.
See above.
Cheers,
Joe
--
RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG
From danny at danysek.cz Sat Jun 2 06:45:19 2012
From: danny at danysek.cz (Daniel Suchy)
Date: Sat, 02 Jun 2012 13:45:19 +0200
Subject: HE.net BGP origin attribute rewriting
In-Reply-To: <20120602104315.GA23204@gweep.net>
References: <4FC75565.4000404@foobar.org>
<088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com>
<4FC77434.5000306@foobar.org>
<1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com>
<20120531170646.GA2477@pob.ytti.fi> <4FC87B04.20200@danysek.cz>
<20120601173841.GA47560@gweep.net> <4FC90406.1000606@danysek.cz>
<20120602005336.GA7394@gweep.net> <4FC9C068.2070506@danysek.cz>
<20120602104315.GA23204@gweep.net>
Message-ID: <4FC9FCCF.8040808@danysek.cz>
On 06/02/2012 12:43 PM, Joe Provo wrote:
> Last post on this topic for me. You seem to wish to argue
> against the lessons of history and the reality of running
> a network on the global Internet.
Based on observations from routeviews / RIPE RIS / other public sources,
overwriting BGP origin isn't a common practice. I did some analysis
before I opened this topic.
>From tier-1 networks, only Level3 seems to do this, from other major
networks only HE. Based on network listed at
http://en.wikipedia.org/wiki/Tier_1_network, there're 2 of 22 major (and
only 11 tier-1) worldwide networks performing origin overwritting.
That's really not a representation of common and widely used practice.
I'm not arguing with common practice on the internet. Majority doesn't
touch origin attribute...
(and yes, basically I don't care about pure tier-2/3 networks, their
impact isn't peremptory in terms of their global impact)
> The two issues are orthogonal. Deaggregating sources have
> been cost-shifting [in a highly visible and easily examined
> and often trivially-filtered] manner for ages.
In global table, there's 41% overhead, in terms of prefixes announced. I
don't think it's trivial to filter this overhead. If you're correct (I
don't think so), why there's this huge ammount of unfiltered
deaggregated prefixes in global table? Because it's easier to buy new
hardware.
> A midspan network deaggregating someone else's prefixes is
> broken and gets called out, generally by the originator if
> they have a clue.
This is bad at all - but sometimes also happens with huge impact and
this is historically documented on some cases like Pakistan
Telecom/Youtube. And this happened, even you said that filtering is
trivial...
- Daniel
From bking at inline.com Sat Jun 2 07:14:13 2012
From: bking at inline.com (Bryan King)
Date: Sat, 2 Jun 2012 07:14:13 -0500
Subject: limestone networks abuse department
Message-ID: <2E2217480B29844BA5E3B4A4BEACE51DF97AF947DE@TCNMAIL1>
...Or lack thereof...
Anyone on list from Limestone that can respond to continued abuse complaints please contact me off list.
bryan king| Internet Department Director
InLine> Solutions Through Technology
600 Lakeshore Pkwy
Birmingham AL, 35209
205-278-8139 [p]
205-314-7729 [f]
bking at inline.com
www.InLine.com
All Quotes from InLine are only valid for 30 days. This message and any attached files may contain confidential information and are intended solely for the message recipient. If you are not the message recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.
From caldcv at gmail.com Sat Jun 2 08:37:31 2012
From: caldcv at gmail.com (Chris)
Date: Sat, 2 Jun 2012 09:37:31 -0400
Subject: limestone networks abuse department
In-Reply-To: <2E2217480B29844BA5E3B4A4BEACE51DF97AF947DE@TCNMAIL1>
References: <2E2217480B29844BA5E3B4A4BEACE51DF97AF947DE@TCNMAIL1>
Message-ID:
Continued abuse complaints?
Time to contact the uplink. Shoot me an email off list and I'll help
you how I can because I lean hard on uplinks in regards to hosting
companies ignoring the Wordpress spam problem
On Sat, Jun 2, 2012 at 8:14 AM, Bryan King wrote:
> ...Or lack thereof...
>
> Anyone on list from Limestone that can respond to continued abuse complaints please contact me off list.
>
>
> bryan king| Internet Department Director
> InLine> Solutions Through Technology
> 600 Lakeshore Pkwy
> Birmingham AL, 35209
> 205-278-8139?[p]
> 205-314-7729?[f]
> bking at inline.com
> www.InLine.com
>
> All Quotes from InLine are only valid for 30 days. This message and any attached files may contain confidential information and are intended solely for the message recipient. If you are not the message recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.
>
>
--
--C
"The dumber people think you are, the more surprised they're going to
be when you kill them." - Sir William Clayton
From j at arpa.com Sat Jun 2 12:06:28 2012
From: j at arpa.com (jamie rishaw)
Date: Sat, 2 Jun 2012 12:06:28 -0500
Subject: limestone networks abuse department
In-Reply-To: <2E2217480B29844BA5E3B4A4BEACE51DF97AF947DE@TCNMAIL1>
References: <2E2217480B29844BA5E3B4A4BEACE51DF97AF947DE@TCNMAIL1>
Message-ID:
Go top down.
Gary Kendall - CEO
Logan Vig - CTO
(All names should be considered "in quotes" as, well, do these people
exist?)
Their 'Interim Designation' (copyright) person of record:
Anthony Winters (7/1/2011)
Same tel, fax 242-3600.
Tho, from previous experience both here and irl, lstn peeps dont seem too
responsive. Given their last address is a UPS store, well, good luck.
If you -really- want to rattle some cages:
http://www.databank.com/company/leadership.html appear to be bldg owners at
their current(?) addr (dctr bldg), and, well, .. should get you somewhere.
-j
On Sat, Jun 2, 2012 at 7:14 AM, Bryan King wrote:
> ...Or lack thereof...
>
> Anyone on list from Limestone that can respond to continued abuse
> complaints please contact me off list.
>
>
> bryan king| Internet Department Director
> InLine> Solutions Through Technology
> 600 Lakeshore Pkwy
> Birmingham AL, 35209
> 205-278-8139 [p]
> 205-314-7729 [f]
> bking at inline.com
> www.InLine.com
>
> All Quotes from InLine are only valid for 30 days. This message and any
> attached files may contain confidential information and are intended solely
> for the message recipient. If you are not the message recipient you are
> notified that disclosing, copying, distributing or taking any action in
> reliance on the contents of this information is strictly prohibited. E-mail
> transmission cannot be guaranteed to be secure or error-free as information
> could be intercepted, corrupted, lost, destroyed, arrive late or
> incomplete, or contain viruses. The sender therefore does not accept
> liability for any errors or omissions in the contents of this message,
> which arise as a result of e-mail transmission. If verification is required
> please request a hard-copy version.
>
>
>
--
Jamie Rishaw // .com.arpa at j
Dear NANOG:
I seek pricing on Comcast AS7922 paid peer at following commit level:
1G
10G
100G
Please reply in private and I will sum up on list.
Sincerely,
Nabil
From jmaslak at antelope.net Sat Jun 2 18:54:55 2012
From: jmaslak at antelope.net (Joel Maslak)
Date: Sat, 2 Jun 2012 17:54:55 -0600
Subject: Comcast Paid Peer Pricing
In-Reply-To:
References:
Message-ID: <78B56A9A-D2EE-4DE6-90EE-C27ADDDDB166@antelope.net>
On Jun 2, 2012, at 3:08 PM, Nabil Sharma wrote:
> Dear NANOG:
> I seek pricing on Comcast AS7922 paid peer at following commit level:
> 1G
> 10G
> 100G
> Please reply in private and I will sum up on list.
> Sincerely,
> Nabil
I'd suggest contact Comcast sales.
From streiner at cluebyfour.org Sat Jun 2 18:57:11 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Sat, 2 Jun 2012 19:57:11 -0400 (EDT)
Subject: Comcast Paid Peer Pricing
In-Reply-To:
References:
Message-ID:
On Sat, 2 Jun 2012, Nabil Sharma wrote:
> Dear NANOG:
> I seek pricing on Comcast AS7922 paid peer at following commit level:
> 1G
> 10G
> 100G
> Please reply in private and I will sum up on list.
Perhaps these would be worth reviewing?
http://www.concast.com/peering/
http://www.comcast.com/dedicatedinternet/?SCRedirect=true
http://as7922.peeringdb.com/
Your best bet would be to hit up their sales contact if you want pricing
on non-SFI peering.
jms
From apishdadi at gmail.com Sat Jun 2 19:44:53 2012
From: apishdadi at gmail.com (Ameen Pishdadi)
Date: Sat, 2 Jun 2012 19:44:53 -0500
Subject: Comcast Paid Peer Pricing
In-Reply-To:
References:
Message-ID: <7CE63E7C-9B7F-4FE9-8B5A-CF2B02891A92@gmail.com>
Concast I love it!!
Thanks,
Ameen Pishdadi
On Jun 2, 2012, at 6:57 PM, "Justin M. Streiner" wrote:
> On Sat, 2 Jun 2012, Nabil Sharma wrote:
>
>> Dear NANOG:
>> I seek pricing on Comcast AS7922 paid peer at following commit level:
>> 1G
>> 10G
>> 100G
>> Please reply in private and I will sum up on list.
>
> Perhaps these would be worth reviewing?
>
> http://www.concast.com/peering/
> http://www.comcast.com/dedicatedinternet/?SCRedirect=true
> http://as7922.peeringdb.com/
>
> Your best bet would be to hit up their sales contact if you want pricing on non-SFI peering.
>
> jms
>
From nabilsharma at hotmail.com Sat Jun 2 23:41:34 2012
From: nabilsharma at hotmail.com (Nabil Sharma)
Date: Sun, 3 Jun 2012 04:41:34 +0000
Subject: Comcast Paid Peer Pricing
In-Reply-To: <7CE63E7C-9B7F-4FE9-8B5A-CF2B02891A92@gmail.com>
References: ,
,
<7CE63E7C-9B7F-4FE9-8B5A-CF2B02891A92@gmail.com>
Message-ID:
I am not allowed to sign NDA, can someone please send me sample pricing in private mail?
Sincerely,
Nabil
> From: apishdadi at gmail.com
> Subject: Re: Comcast Paid Peer Pricing
> Date: Sat, 2 Jun 2012 19:44:53 -0500
> To: streiner at cluebyfour.org
> CC: nanog at nanog.org
>
> Concast I love it!!
>
> Thanks,
> Ameen Pishdadi
>
>
> On Jun 2, 2012, at 6:57 PM, "Justin M. Streiner" wrote:
>
> > On Sat, 2 Jun 2012, Nabil Sharma wrote:
> >
> >> Dear NANOG:
> >> I seek pricing on Comcast AS7922 paid peer at following commit level:
> >> 1G
> >> 10G
> >> 100G
> >> Please reply in private and I will sum up on list.
> >
> > Perhaps these would be worth reviewing?
> >
> > http://www.concast.com/peering/
> > http://www.comcast.com/dedicatedinternet/?SCRedirect=true
> > http://as7922.peeringdb.com/
> >
> > Your best bet would be to hit up their sales contact if you want pricing on non-SFI peering.
> >
> > jms
> >
>
From alter3d at alter3d.ca Sat Jun 2 23:45:38 2012
From: alter3d at alter3d.ca (Peter Kristolaitis)
Date: Sun, 03 Jun 2012 00:45:38 -0400
Subject: Comcast Paid Peer Pricing
In-Reply-To:
References: ,
,
<7CE63E7C-9B7F-4FE9-8B5A-CF2B02891A92@gmail.com>
Message-ID: <4FCAEBF2.2060402@alter3d.ca>
You're not allowed to sign an NDA, but you expect other people to
violate the ones that they've signed by disclosing pricing to you?
Yeah, I'm sure everyone will get right on that...
- Pete
On 6/3/2012 12:41 AM, Nabil Sharma wrote:
> I am not allowed to sign NDA, can someone please send me sample pricing in private mail?
>
> Sincerely,
> Nabil
>
>> From: apishdadi at gmail.com
>> Subject: Re: Comcast Paid Peer Pricing
>> Date: Sat, 2 Jun 2012 19:44:53 -0500
>> To: streiner at cluebyfour.org
>> CC: nanog at nanog.org
>>
>> Concast I love it!!
>>
>> Thanks,
>> Ameen Pishdadi
>>
>>
>> On Jun 2, 2012, at 6:57 PM, "Justin M. Streiner" wrote:
>>
>>> On Sat, 2 Jun 2012, Nabil Sharma wrote:
>>>
>>>> Dear NANOG:
>>>> I seek pricing on Comcast AS7922 paid peer at following commit level:
>>>> 1G
>>>> 10G
>>>> 100G
>>>> Please reply in private and I will sum up on list.
>>> Perhaps these would be worth reviewing?
>>>
>>> http://www.concast.com/peering/
>>> http://www.comcast.com/dedicatedinternet/?SCRedirect=true
>>> http://as7922.peeringdb.com/
>>>
>>> Your best bet would be to hit up their sales contact if you want pricing on non-SFI peering.
>>>
>>> jms
>>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4418 bytes
Desc: S/MIME Cryptographic Signature
URL:
From alter3d at alter3d.ca Sun Jun 3 00:19:44 2012
From: alter3d at alter3d.ca (Peter Kristolaitis)
Date: Sun, 03 Jun 2012 01:19:44 -0400
Subject: Comcast Paid Peer Pricing
In-Reply-To:
References: , ,
, ,
<7CE63E7C-9B7F-4FE9-8B5A-CF2B02891A92@gmail.com>,
,
<4FCAEBF2.2060402@alter3d.ca>
Message-ID: <4FCAF3F0.8090406@alter3d.ca>
If you believe that they have no legal right to keep the data private,
then obviously any NDA surrounding that data is unenforceable, so you
should have no problems signing it yourself and then completely ignoring
its terms as you're asking others to do. I'm sure the judge at your
civil suit will find your arguments interesting and will weigh them
appropriately.
Keep in mind that anyone who provides pricing data to you may not only
be violating any Comcast NDA that they may have signed, but possibly the
NDA they have with their employer as well. Even if there is no NDA
covering the ComcastEmployer relationship, any employee of Employer
may be legally bound not to discuss the terms of ANY of Employer's
contracts with third parties.
- Pete
On 6/3/2012 1:03 AM, Nabil Sharma wrote:
> Yes sir. They're a cable monopoly, I don't think they have any legal
> or moral right to keep the data private.
>
> > Date: Sun, 3 Jun 2012 00:45:38 -0400
> > From: alter3d at alter3d.ca
> > To: nanog at nanog.org
> > Subject: Re: Comcast Paid Peer Pricing
> >
> > You're not allowed to sign an NDA, but you expect other people to
> > violate the ones that they've signed by disclosing pricing to you?
> > Yeah, I'm sure everyone will get right on that...
> >
> > - Pete
> >
> >
> > On 6/3/2012 12:41 AM, Nabil Sharma wrote:
> > > I am not allowed to sign NDA, can someone please send me sample
> pricing in private mail?
> > >
> > > Sincerely,
> > > Nabil
> > >
> > >> From: apishdadi at gmail.com
> > >> Subject: Re: Comcast Paid Peer Pricing
> > >> Date: Sat, 2 Jun 2012 19:44:53 -0500
> > >> To: streiner at cluebyfour.org
> > >> CC: nanog at nanog.org
> > >>
> > >> Concast I love it!!
> > >>
> > >> Thanks,
> > >> Ameen Pishdadi
> > >>
> > >>
> > >> On Jun 2, 2012, at 6:57 PM, "Justin M.
> Streiner" wrote:
> > >>
> > >>> On Sat, 2 Jun 2012, Nabil Sharma wrote:
> > >>>
> > >>>> Dear NANOG:
> > >>>> I seek pricing on Comcast AS7922 paid peer at following commit
> level:
> > >>>> 1G
> > >>>> 10G
> > >>>> 100G
> > >>>> Please reply in private and I will sum up on list.
> > >>> Perhaps these would be worth reviewing?
> > >>>
> > >>> http://www.concast.com/peering/
> > >>> http://www.comcast.com/dedicatedinternet/?SCRedirect=true
> > >>> http://as7922.peeringdb.com/
> > >>>
> > >>> Your best bet would be to hit up their sales contact if you want
> pricing on non-SFI peering.
> > >>>
> > >>> jms
> > >>>
> > >
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4418 bytes
Desc: S/MIME Cryptographic Signature
URL:
From mark.tinka at seacom.mu Sun Jun 3 02:05:31 2012
From: mark.tinka at seacom.mu (Mark Tinka)
Date: Sun, 3 Jun 2012 09:05:31 +0200
Subject: Comcast Paid Peer Pricing
In-Reply-To:
References:
<7CE63E7C-9B7F-4FE9-8B5A-CF2B02891A92@gmail.com>
Message-ID: <201206030905.31855.mark.tinka@seacom.mu>
On Sunday, June 03, 2012 06:41:34 AM Nabil Sharma wrote:
> I am not allowed to sign NDA, can someone please send me
> sample pricing in private mail?
Then find someone in your company who will and use that
channel, Nabil.
Alternatively, have you tried to find out whether Comcast
could actually quote you without needing an NDA? They might
have a provision for that (generic, poorly-discounted
pricing, not to give themselves away until you're serious,
e.t.c.).
Just don't expect the folk here to do that work for you,
Nabil.
Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL:
From streiner at cluebyfour.org Sun Jun 3 04:33:53 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Sun, 3 Jun 2012 05:33:53 -0400 (EDT)
Subject: Comcast Paid Peer Pricing
In-Reply-To:
References: ,
,
<7CE63E7C-9B7F-4FE9-8B5A-CF2B02891A92@gmail.com>
Message-ID:
On Sun, 3 Jun 2012, Nabil Sharma wrote:
> I am not allowed to sign NDA, can someone please send me sample pricing
> in private mail?
I didn't see any requirement to sign an NDA for their dedicated
non-transit product, which is essentially what you were asking for. If
you want to do SFI (assuming your network meets Comcast's criteria for
SFI), then there would be an NDA.
jms
>> From: apishdadi at gmail.com
>> Subject: Re: Comcast Paid Peer Pricing
>> Date: Sat, 2 Jun 2012 19:44:53 -0500
>> To: streiner at cluebyfour.org
>> CC: nanog at nanog.org
>>
>> Concast I love it!!
>>
>> Thanks,
>> Ameen Pishdadi
>>
>>
>> On Jun 2, 2012, at 6:57 PM, "Justin M. Streiner" wrote:
>>
>>> On Sat, 2 Jun 2012, Nabil Sharma wrote:
>>>
>>>> Dear NANOG:
>>>> I seek pricing on Comcast AS7922 paid peer at following commit level:
>>>> 1G
>>>> 10G
>>>> 100G
>>>> Please reply in private and I will sum up on list.
>>>
>>> Perhaps these would be worth reviewing?
>>>
>>> http://www.concast.com/peering/
>>> http://www.comcast.com/dedicatedinternet/?SCRedirect=true
>>> http://as7922.peeringdb.com/
>>>
>>> Your best bet would be to hit up their sales contact if you want pricing on non-SFI peering.
>>>
>>> jms
>>>
>>
>
From streiner at cluebyfour.org Sun Jun 3 04:53:17 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Sun, 3 Jun 2012 05:53:17 -0400 (EDT)
Subject: Comcast Paid Peer Pricing
In-Reply-To:
References: ,
,
<7CE63E7C-9B7F-4FE9-8B5A-CF2B02891A92@gmail.com>
Message-ID:
On Sun, 3 Jun 2012, Nabil Sharma wrote:
> I am not allowed to sign NDA, can someone please send me sample pricing
> in private mail?
Since it's not entirely clear if you're asking about SFI or not...
Entering into something like an SFI agreement with a large national
network is typically something that 1. your company's legal counsel would
need to review, and 2. Someone pretty high up in your company would need
to approve and sign, because it can potentially obligate your company to
make significant ongoing infrastructure investments to remain in
compliance with your SFI agreement. If your company has a network that's
large enough to warrant SFI, it would also stand to reason that they
already have business and legal processes in place for dealing with
things like this - something a little more 'official' than hassling
people on a public mailing list, from a Hotmail address ;)
If anyone on this list is doing SFI with Comcast, they are not going to
risk violating their NDA by providing what could be considered
confidential and proprietary information to a third party, let alone a
complete stranger.
If you're not asking about SFI, call/email the sales contact that was
listed on their dedicated internet access page, and get a quote. I saw no
indication that you needed an NDA to get a quote for their paid peering
product. All I saw was an order form that you would need to fill out and
email to the sales contact. As others mave mentioned, Comcast might not
provide the best pricing right off the bat, but it at least would get you
a number that you can use for budgetary/planning purposes.
jms
From tom at dyn.com Sun Jun 3 06:06:10 2012
From: tom at dyn.com (Tom Daly)
Date: Sun, 3 Jun 2012 07:06:10 -0400 (EDT)
Subject: NANOG 55: Submit your Lightning Talks!
In-Reply-To: <931573253.20924661.1338721212313.JavaMail.root@zmail-01.mht.dyndns.com>
Message-ID: <587063757.20924696.1338721570015.JavaMail.root@zmail-01.mht.dyndns.com>
Hello NANOG 55'ers,
Welcome to Vancouver. On behalf of the NANOG Program Committee, I'm pleased to announce that we're accepting Lightning Talk submissions via our tool at https://pc.nanog.org/. Log in, submit a talk, and wait. We'll be announcing the first round of LTs late this evening.
How does it work?
- You come up with an idea for a 10 minute talk. You submit an abstract to the tool at https://pc.nanog.org.
- The Program Committee reviews the talks in the tool, and each PC member rates their top 3 choices.
- Around 10pm Sunday and Tuesday evenings, we'll select the top 3 rated talks in the tool, and include them in the following day's Lightning Talk session.
- If you are selected to present a Lightning Talk, you'll be notified by email on how to submit your slides to the NANOG PC.
No idea is too ridiculous for a talk! No topic is too crazy! Submit your talk now and enjoy the rush of a being a real, live, NANOG presenter!
For the NANOG PC,
Tom Daly
--
Tom Daly
@tomdyninc | tom at dyn.com | http://dyn.com
Dyn | 150 Dow Street | Manchester, NH 03101, USA
From ren.provo at gmail.com Sun Jun 3 10:44:14 2012
From: ren.provo at gmail.com (Ren Provo)
Date: Sun, 3 Jun 2012 11:44:14 -0400
Subject: Comcast Paid Peer Pricing
In-Reply-To:
References:
Message-ID:
What is your ASN Nabil so I can find out what you submitted for a
request, including scope and term. -ren
On Sat, Jun 2, 2012 at 5:08 PM, Nabil Sharma wrote:
>
> Dear NANOG:
> I seek pricing on Comcast AS7922 paid peer at following commit level:
> 1G
> 10G
> 100G
> Please reply in private and I will sum up on list.
> Sincerely,
> Nabil
>
From j at arpa.com Sun Jun 3 11:23:42 2012
From: j at arpa.com (jamie rishaw)
Date: Sun, 3 Jun 2012 11:23:42 -0500
Subject: Comcast Paid Peer Pricing
In-Reply-To:
References:
Message-ID:
..I was waiting for Ren to shut this thread Down. :)
Nabil: reply to Ren directly, off list. You'll be in good hands.
j
On Jun 3, 2012 10:44 AM, "Ren Provo" wrote:
> What is your ASN Nabil so I can find out what you submitted for a
> request, including scope and term. -ren
>
> On Sat, Jun 2, 2012 at 5:08 PM, Nabil Sharma
> wrote:
> >
> > Dear NANOG:
> > I seek pricing on Comcast AS7922 paid peer at following commit level:
> > 1G
> > 10G
> > 100G
> > Please reply in private and I will sum up on list.
> > Sincerely,
> > Nabil
> >
>
>
From me at anuragbhatia.com Sun Jun 3 14:35:37 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Mon, 4 Jun 2012 01:05:37 +0530
Subject: Questions about anycasting setup
In-Reply-To: <20120312082532.GD17726@h.detebe.org>
References:
<20120309081131.GC17726@h.detebe.org>
<4F59C701.3090503@altadena.net>
<2763367C-26BA-4330-812E-C5898E154D14@gibbard.org>
<20120312082532.GD17726@h.detebe.org>
Message-ID:
Hello everyone
Thought to re-open to this thread and discuss couple of doubts I have in
mind regarding the same.
I tried doing anycasting with 3 nodes, and seems like it didn't worked well
at all. It seems like ISPs prefer their own or their customer route (which
is our transit provider) and there is almost no "short/local route" effect.
I am presently using Charter + Cogent/Gblx + Tinet for this setup.
I was looking for some advise over this issue:
1. How to deal with ISPs not prefering local node on their peers network
and going to far off node on their own/or customer network? Is it just
normal and there's no fix by any BGP announcement method/conf file
parameter? Should one prefer taking transit for all locations from same ISP?
2. I am using Quagga on all instances. Any advise on configuration file
parameters specifically for anycasting instance? (I would be happy to share
existing conf. is required). I did tried AS path prepending, but seems like
it didn't helped much (or may be I fail to get it working). What are
possible parameters one can have in conf for anycasting case (BGP MED's)?
3. Is putting singlehommed nodes with no peering and transit from single
ISP was poor idea? I wonder how other small players do it? Do you take
multiple upstreams for all anycasting DNS nodes?
Though route pull off is pretty much instance, and I see no problems with
it. Also, I have not got the node in EU up yet (which will be under colo's
network which is under Telia). I guess since distance in EU with US is way
higher then between our domestic US nodes, so probably I will see
local/near routing effect with EU server. But still clueless on how to get
it working in current setup.
Appreciate everyone's comments and help.
Thanks.
--
Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!
Linkedin |
Twitter|
Google+
From woody at pch.net Sun Jun 3 16:11:49 2012
From: woody at pch.net (Bill Woodcock)
Date: Sun, 3 Jun 2012 14:11:49 -0700
Subject: Questions about anycasting setup
In-Reply-To:
References:
<20120309081131.GC17726@h.detebe.org> <4F59C701.3090503@altadena.net>
<2763367C-26BA-4330-812E-C5898E154D14@gibbard.org>
<20120312082532.GD17726@h.detebe.org>
Message-ID: <3C5E8697-8AFD-4A4B-9A4F-4AD48BE71F52@pch.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Jun 3, 2012, at 12:35 PM, Anurag Bhatia wrote:
> I tried doing anycasting with 3 nodes, and seems like it didn't worked well
> at all. It seems like ISPs prefer their own or their customer route (which
> is our transit provider) and there is almost no "short/local route" effect.
Correct. That's why you need to use the same transit providers at each location.
http://www.pch.net/resources/papers//dns-service-architecture/dns-service-architecture-v11.pdf
Slides 20-29.
-Bill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJPy9MWAAoJEG+kcEsoi3+HJkkP/jP9ZVGlIs53qs93jWth6tjt
M/zvVBs8EhJrn9RQ9VxfJ1VNmJ4cFILV52PGXarDhN7Gkc/fke0mh3Jbb8rOh9k9
jhFFV0QuiF/vda4QNskzXJGvWTkdl0vhq5BMqcKOLpk2zVMBvvNJziEoFgpxeXaz
ghlgDxOGZ1Fq/sSgQndfx/bYPBOq/N5zkfsNQSW8CSrHwuuXIW3C/XgEbHLEbUGG
r4w0vtrdtjrrlYs301YjTVXcFPw4Xs/byor+Sqf8XvIOiQbgAe0Ap9p3/kBHjAZf
aKiTOncqCHgzgP4hJ3elvyd8agkLsGo2kvyReCxAho8lGjAbK/IYzj4npIh0JXj+
LPXjQgDpvq42ly3TJQsugiHHY98sqesDzKe6aQqruChDEqSctL3r8u5F19Nm39Pu
6WIGC6UbJVDol96BVqkTbfMKtbHuzRij2jsc+Dd0GkOLy2Zy095weT1xOh/TDQCj
QIN8u4BDFTk+KxVb86a/mWKmcD4lfM6IbOOR8dg2DWmnNlTF2+4DRz2WjYhnqQwg
NN1otUVVMrdIAOa5RJSVOJ5Q3R1AK93vCK4QGYrHCs8sw4GMtieqVS4Q1I8Hn28v
gKm7POiArujZkzOcQHmyo28zClRrzKkL1Z1P2wJOvos2briuJhhyCeaDaWU0ux3R
5EmMxRpTvCsm6MzEvQkI
=D+uQ
-----END PGP SIGNATURE-----
From jmaimon at ttec.com Sun Jun 3 20:38:58 2012
From: jmaimon at ttec.com (Joe Maimon)
Date: Sun, 03 Jun 2012 21:38:58 -0400
Subject: IPv6 day and tunnels
Message-ID: <4FCC11B2.2090405@ttec.com>
Well, IPv6 day isnt here yet, and my first casualty is the browser on
the wife's machine, firefox now configured to not query AAAA.
Now www.facebook.com loads again.
Looks like a tunnel mtu issue. I have not as of yet traced the
definitive culprit, who is (not) sending ICMP too big, who is (not)
receiving them, etc.
www.arin.net works and worked for years. www.facebook.com stopped June 1.
So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly?
Or was the fix incorporating the breakage into the basic design?
In IPv4 I can make tunneling just work nearly all of the time. So I have
to munge a tcp mss header, or clear a df-bit, or fragment the
encapsulated packet when all else fails, but at least the tools are
there. And on the host, /proc/sys/net
In IPv6, it seems my options are a total throwback, with the best one
turning the sucker off. Nobody (on that station) needs it anyways.
Joe
From cb.list6 at gmail.com Sun Jun 3 20:59:13 2012
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Sun, 3 Jun 2012 18:59:13 -0700
Subject: IPv6 day and tunnels
In-Reply-To: <4FCC11B2.2090405@ttec.com>
References: <4FCC11B2.2090405@ttec.com>
Message-ID:
On Sun, Jun 3, 2012 at 6:38 PM, Joe Maimon wrote:
> Well, IPv6 day isnt here yet, and my first casualty is the browser on the
> wife's machine, firefox now configured to not query AAAA.
>
> Now www.facebook.com loads again.
>
> Looks like a tunnel mtu issue. I have not as of yet traced the definitive
> culprit, who is (not) sending ICMP too big, who is (not) receiving them,
> etc.
>
> www.arin.net works and worked for years. www.facebook.com stopped June 1.
>
> So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly?
>
> Or was the fix incorporating the breakage into the basic design?
>
> In IPv4 I can make tunneling just work nearly all of the time. So I have to
> munge a tcp mss header, or clear a df-bit, or fragment the encapsulated
> packet when all else fails, but at least the tools are there. And on the
> host, /proc/sys/net
>
> In IPv6, it seems my options are a total throwback, with the best one
> turning the sucker off. Nobody (on that station) needs it anyways.
>
> Joe
>
#1 don't tunnel unless you really need to.
#2 see #1
#3 use happy eyeballs, http://tools.ietf.org/html/rfc6555, Chrome has
a good implementation, but this does not solve MTU issues.
#4 MSS hacks work at the TCP layer and still work regardless of IPv4 or IPv6.
#5 According to the IETF, MSS hacks do not exist and neither do MTU
issues http://www.ietf.org/mail-archive/web/v6ops/current/msg12933.html
PSA time: Please use http://test-ipv6.com/ and pass this good advice
around to the people you know.
Thanks,
Cameron
From jmaimon at ttec.com Sun Jun 3 21:05:40 2012
From: jmaimon at ttec.com (Joe Maimon)
Date: Sun, 03 Jun 2012 22:05:40 -0400
Subject: IPv6 day and tunnels
In-Reply-To: <4FCC11B2.2090405@ttec.com>
References: <4FCC11B2.2090405@ttec.com>
Message-ID: <4FCC17F4.3020105@ttec.com>
Joe Maimon wrote:
> Looks like a tunnel mtu issue. I have not as of yet traced the
> definitive culprit, who is (not) sending ICMP too big, who is (not)
> receiving them, etc.
>
The culprit is the v6 tunnel, which wanders into v4 ipsec/gre tunnels,
which means the best fix is ipv6 mtu 1280 on the tunnels, and possibly
on the hosts. PMTUD works fine, just comes up with the wrong answer.
1280, the new 1500.
> Joe
From jmaimon at ttec.com Sun Jun 3 21:19:57 2012
From: jmaimon at ttec.com (Joe Maimon)
Date: Sun, 03 Jun 2012 22:19:57 -0400
Subject: IPv6 day and tunnels
In-Reply-To:
References: <4FCC11B2.2090405@ttec.com>
Message-ID: <4FCC1B4D.8010204@ttec.com>
Cameron Byrne wrote:
>>
>
> #1 don't tunnel unless you really need to.
Tunnels are ipv4 only now?
>
> #2 see #1
>
> #3 use happy eyeballs, http://tools.ietf.org/html/rfc6555, Chrome has
> a good implementation, but this does not solve MTU issues.
Because the initial connections are made just fine.
PMTUD with probing should work, but does not seem to. Probably a (lack
of) deployment issue.
>
> #4 MSS hacks work at the TCP layer and still work regardless of IPv4 or IPv6.
But the equipment needs to support it. Again IPv6 lags.
>
> #5 According to the IETF, MSS hacks do not exist and neither do MTU
> issues http://www.ietf.org/mail-archive/web/v6ops/current/msg12933.html
Thanks for that. I expect soon tunnels wont either.
>
> PSA time: Please use http://test-ipv6.com/ and pass this good advice
> around to the people you know.
Excellent site/tool.
>
> Thanks,
>
> Cameron
>
>
Thank you.
Joe
From jmaslak at antelope.net Sun Jun 3 21:33:40 2012
From: jmaslak at antelope.net (Joel Maslak)
Date: Sun, 3 Jun 2012 20:33:40 -0600
Subject: IPv6 day and tunnels
In-Reply-To: <4FCC11B2.2090405@ttec.com>
References: <4FCC11B2.2090405@ttec.com>
Message-ID: <1F6EFAED-340C-4659-A59D-58800C079A9A@antelope.net>
On Jun 3, 2012, at 7:38 PM, Joe Maimon wrote:
> www.arin.net works and worked for years. www.facebook.com stopped June 1.
>
> So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly?
It doesn't fix the fragmentation issues. It assumes working PMTU.
For what it's worth, I also use a tunnel without issue to reach www.facebook.com via IPv6, with an MTU of 1476 (since it's running over a 1492 byte IPv4 PPoE tunnel...).
From mysidia at gmail.com Sun Jun 3 21:49:47 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 3 Jun 2012 21:49:47 -0500
Subject: Wacky Weekend: The '.secure' gTLD
In-Reply-To: <30056137.6920.1338509482343.JavaMail.root@benjamin.baylink.com>
References: <15376026.6918.1338509096625.JavaMail.root@benjamin.baylink.com>
<30056137.6920.1338509482343.JavaMail.root@benjamin.baylink.com>
Message-ID:
On 5/31/12, Jay Ashworth wrote:
> HTTP redirects funneling connections towards the appropriate TLS-encrypted
> site), use DNSSEC, and deploy DomainKeys Identified Mail (DKIM) for spam
The "Except for HTTP redirects" part is a gigantonormous hole. A
MITM attacker on a LAN can intercept traffic to the non-HTTPS redirect
site and proxy this traffic. The ".SECURE" in the TLD looks like a
user interface declaration, the user will believe that the appearance
of .SECURE means their connection is encrypted, even when it is not.
The TLD should probably not be allowed, because it is confusing, it
looks like a User Interface Declaration, that the site is proven to
be secure, but none of the registry's proposed measures provide a
reliable assurance; it may lead the user to believe that ".SECURE" is
a technical indication that ensures the site is actually secure.
Even HTTPS and EV+SSL do not provide such a strong UI declaration. A
UI declaration should not be able to be made by the registration of a
domain alone, the software displaying the URL should be responsible
for UI declarations.
This may result in mixed signals if a site on a SLD under .SECURE
is actually compromised, which is more harmful than having no UI
declaration.
Absent a new RFC requirement for browsers to connect to .SECURE TLD
sites using only HTTPS,
their "Non-HTTPS Redirect to HTTPS pages" are just as susceptible
to MITM hijacking as any non-HTTPS site.
> prevention. In addition, Artemis would employ a rigorous screening process
> to verify registrants' identities (including reviewing articles of incorporation
> and human interviews), and routinely conduct security scans of registered
> sites. The venture has $9.6 million (US) in funding provided by Artemis'
This is expensive, a good way to keep the TLD out of use except by
large corporations,
and is therefore of very limited value to the community. Required
to meet a generally accepted standard of security with third party
auditing would be more useful.
"Security scans" by one provider aren't really good enough. Automated
scans cannot detect insidious exploitability issues; they typically
detect and flag non-issues to justify their existence, and fail to
detect glaring issues such as session tracking in a manner vulnerable
to CSRF.
More importantly; remote periodic scans cannot detect compromise of
the site or ensure reasonable internal security practices, when the
impact is information leak, intruders don't always insert malware on
the front page for a scanner to pick up.
--
-JH
From cmorris at cs.odu.edu Sun Jun 3 22:06:09 2012
From: cmorris at cs.odu.edu (Charles Morris)
Date: Sun, 3 Jun 2012 23:06:09 -0400
Subject: Wacky Weekend: The '.secure' gTLD
In-Reply-To: <30056137.6920.1338509482343.JavaMail.root@benjamin.baylink.com>
References: <15376026.6918.1338509096625.JavaMail.root@benjamin.baylink.com>
<30056137.6920.1338509482343.JavaMail.root@benjamin.baylink.com>
Message-ID:
No. Let's go the opposite direction and make DNS a decentralized trust model. :)
> Digress.
From marka at isc.org Sun Jun 3 22:14:15 2012
From: marka at isc.org (Mark Andrews)
Date: Mon, 04 Jun 2012 13:14:15 +1000
Subject: IPv6 day and tunnels
In-Reply-To: Your message of "Sun, 03 Jun 2012 21:38:58 -0400."
<4FCC11B2.2090405@ttec.com>
References: <4FCC11B2.2090405@ttec.com>
Message-ID: <20120604031416.0B4D02138073@drugs.dv.isc.org>
In message <4FCC11B2.2090405 at ttec.com>, Joe Maimon writes:
> Well, IPv6 day isnt here yet, and my first casualty is the browser on
> the wife's machine, firefox now configured to not query AAAA.
>
> Now www.facebook.com loads again.
>
> Looks like a tunnel mtu issue. I have not as of yet traced the
> definitive culprit, who is (not) sending ICMP too big, who is (not)
> receiving them, etc.
>
> www.arin.net works and worked for years. www.facebook.com stopped June 1.
>
> So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly?
>
> Or was the fix incorporating the breakage into the basic design?
>
> In IPv4 I can make tunneling just work nearly all of the time. So I have
> to munge a tcp mss header, or clear a df-bit, or fragment the
> encapsulated packet when all else fails, but at least the tools are
> there. And on the host, /proc/sys/net
>
> In IPv6, it seems my options are a total throwback, with the best one
> turning the sucker off. Nobody (on that station) needs it anyways.
>
> Joe
If facebook isn't working for you over a tunnel, and other sites are,
complain to the site.
If they don't let through ICMPv6 PTB then the site needs to add
"route change -inet6 change -mtu 1280" or equivalent to every box.
This isn't rocket science. If you choose to break PMTU discovery
then you can take the necessary steps to avoid requiring that PMTU
Discovery works. This is practical for IPv6. For IPv4 it is
impractical to do the same.
The IPv6 Advanced Socket API even has controls so that you can make
the PMTUD choice on a per socket basis.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
From bmanning at vacation.karoshi.com Sun Jun 3 22:26:20 2012
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Mon, 4 Jun 2012 03:26:20 +0000
Subject: IPv6 day and tunnels
In-Reply-To: <4FCC17F4.3020105@ttec.com>
References: <4FCC11B2.2090405@ttec.com> <4FCC17F4.3020105@ttec.com>
Message-ID: <20120604032620.GA14406@vacation.karoshi.com.>
On Sun, Jun 03, 2012 at 10:05:40PM -0400, Joe Maimon wrote:
>
>
> Joe Maimon wrote:
>
> >Looks like a tunnel mtu issue. I have not as of yet traced the
> >definitive culprit, who is (not) sending ICMP too big, who is (not)
> >receiving them, etc.
> >
>
> The culprit is the v6 tunnel, which wanders into v4 ipsec/gre tunnels,
> which means the best fix is ipv6 mtu 1280 on the tunnels, and possibly
> on the hosts. PMTUD works fine, just comes up with the wrong answer.
>
> 1280, the new 1500.
>
>
> >Joe
actually, to be safe, 1220.
/bill
From jeroen at unfix.org Sun Jun 3 22:35:59 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Sun, 03 Jun 2012 20:35:59 -0700
Subject: IPv6 day and tunnels
In-Reply-To: <20120604032620.GA14406@vacation.karoshi.com.>
References: <4FCC11B2.2090405@ttec.com> <4FCC17F4.3020105@ttec.com>
<20120604032620.GA14406@vacation.karoshi.com.>
Message-ID: <4FCC2D1F.3020000@unfix.org>
On 2012-06-03 20:26, bmanning at vacation.karoshi.com wrote:
> On Sun, Jun 03, 2012 at 10:05:40PM -0400, Joe Maimon wrote:
[..]
> actually, to be safe, 1220.
That will work really well with the minimum IPv6 MTU being 1280 ;)
Greets,
Jeroen
From mysidia at gmail.com Sun Jun 3 22:40:02 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 3 Jun 2012 22:40:02 -0500
Subject: IPv6 day and tunnels
In-Reply-To:
References: <4FCC11B2.2090405@ttec.com>
Message-ID:
On 6/3/12, Cameron Byrne wrote:
> On Sun, Jun 3, 2012 at 6:38 PM, Joe Maimon wrote:
[snip]
> #5 According to the IETF, MSS hacks do not exist and neither do MTU
> issues http://www.ietf.org/mail-archive/web/v6ops/current/msg12933.html
They couldn't be more wrong. MTU issues still exist, and not just
with tunnelling,
but tunneling should be an expected scenario for IP.
The protocol IPv6 still handles it very poorly, by still requiring
external ICMP messages,
through the unreliable PTMUD scheme, matters are as bad if not worse
than with IPv4.
It's just so unfortunate that IPv6 couldn't provide a good solution
to one of IP's more troublesome deficiencies.
> Cameron
--
-JH
From jra at baylink.com Sun Jun 3 23:02:08 2012
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 04 Jun 2012 00:02:08 -0400
Subject: Wacky Weekend: The '.secure' gTLD
In-Reply-To:
References: <15376026.6918.1338509096625.JavaMail.root@benjamin.baylink.com>
<30056137.6920.1338509482343.JavaMail.root@benjamin.baylink.com>
Message-ID: <4d6a09f8-31b6-41c7-8827-d73099dbb375@email.android.com>
Note that you've misquoted; that was a reply to my post, possibly 2 levels deep.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Jimmy Hess wrote:
On 5/31/12, Jay Ashworth wrote:
> HTTP redirects funneling connections towards the appropriate TLS-encrypted
> site), use DNSSEC, and deploy DomainKeys Identified Mail (DKIM) for spam
The "Except for HTTP redirects" part is a gigantonormous hole. A
MITM attacker on a LAN can intercept traffic to the non-HTTPS redirect
site and proxy this traffic. The ".SECURE" in the TLD looks like a
user interface declaration, the user will believe that the appearance
of .SECURE means their connection is encrypted, even when it is not.
The TLD should probably not be allowed, because it is confusing, it
looks like a User Interface Declaration, that the site is proven to
be secure, but none of the registry's proposed measures provide a
reliable assurance; it may lead the user to believe that ".SECURE" is
a technical indication that ensures the site is actually secure.
Even HTTPS and EV+SSL do not provide such a strong UI declaration. A
UI declaration should not be able to be made by the registration of a
domain alone, the software displaying the URL should be responsible
for UI declarations.
This may result in mixed signals if a site on a SLD under .SECURE
is actually compromised, which is more harmful than having no UI
declaration.
Absent a new RFC requirement for browsers to connect to .SECURE TLD
sites using only HTTPS,
their "Non-HTTPS Redirect to HTTPS pages" are just as susceptible
to MITM hijacking as any non-HTTPS site.
> prevention. In addition, Artemis would employ a rigorous screening process
> to verify registrants' identities (including reviewing articles of incorporation
> and human interviews), and routinely conduct security scans of registered
> sites. The venture has $9.6 million (US) in funding provided by Artemis'
This is expensive, a good way to keep the TLD out of use except by
large corporations,
and is therefore of very limited value to the community. Required
to meet a generally accepted standard of security with third party
auditing would be more useful.
"Security scans" by one provider aren't really good enough. Automated
scans cannot detect insidious exploitability issues; they typically
detect and flag non-issues to justify their existence, and fail to
detect glaring issues such as session tracking in a manner vulnerable
to CSRF.
More importantly; remote periodic scans cannot detect compromise of
the site or ensure reasonable internal security practices, when the
impact is information leak, intruders don't always insert malware on
the front page for a scanner to pick up.
--
-JH
From kmedcalf at dessus.com Sun Jun 3 23:30:19 2012
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sun, 03 Jun 2012 22:30:19 -0600
Subject: Wacky Weekend: The '.secure' gTLD
In-Reply-To:
Message-ID: <1963017dea9e4841b7a83fb3cb3c9f86@mail.dessus.com>
> This may result in mixed signals if a site on a SLD under .SECURE
> is actually compromised, which is more harmful than having no UI
> declaration.
The greatest advantage of .SECURE is that it will help ensure that all the high-value targets are easy to find.
---
() ascii ribbon campaign against html e-mail
/\ www.asciiribbon.org
From jeroen at unfix.org Sun Jun 3 23:54:12 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Sun, 3 Jun 2012 21:54:12 -0700
Subject: IPv6 day and tunnels
In-Reply-To:
References: <4FCC11B2.2090405@ttec.com>
Message-ID: <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org>
On 3 Jun 2012, at 20:40, Jimmy Hess wrote:
> On 6/3/12, Cameron Byrne wrote:
>> On Sun, Jun 3, 2012 at 6:38 PM, Joe Maimon wrote:
> [snip]
>> #5 According to the IETF, MSS hacks do not exist and neither do MTU
>> issues http://www.ietf.org/mail-archive/web/v6ops/current/msg12933.html
>
> They couldn't be more wrong. MTU issues still exist, and not just
> with tunnelling,
> but tunneling should be an expected scenario for IP.
>
> The protocol IPv6 still handles it very poorly, by still requiring
> external ICMP messages,
> through the unreliable PTMUD scheme, matters are as bad if not worse
> than with IPv4.
As ICMPv6 is an integral part of IPv6 how exactly is ICMP "external"?
You do realize what the function of ICMP is I hope?
If one is so stupid to just block ICMP then one should also accept that one loses functionality.
If the people in the IETF would have decided to inline the headers that are ICMPv6 into the IPv6 header then there for sure would have been people who would have blocked the equivalent of PacketTooBig in there too. As long as people can block stuff they will block stuff that they should not have blocked, nothing the IETF can do about, stupidity exists behind the keyboard.
That said, pMTU discovery works awesomely in the 10+ years that I have been actively been using IPv6, if it does no work for you, find the issue and resolve it. (tracepath is a great tool for this btw)
> It's just so unfortunate that IPv6 couldn't provide a good solution
> to one of IP's more troublesome deficiencies.
Did you ever bother to comment about your supposed issue in the IETF?
Greets,
Jeroen
From mohta at necom830.hpcl.titech.ac.jp Mon Jun 4 00:41:03 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Mon, 04 Jun 2012 14:41:03 +0900
Subject: IPv6 day and tunnels
In-Reply-To: <4FCC11B2.2090405@ttec.com>
References: <4FCC11B2.2090405@ttec.com>
Message-ID: <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp>
Joe Maimon wrote:
> So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly?
Completely wrongly.
> Or was the fix incorporating the breakage into the basic design?
Yes.
Because IPv6 requires ICMP packet too big generated against
multicast, it is designed to cause ICMP implosions, which
means ISPs must filter ICMP packet too big at least against
multicast packets and, as distinguishing them from unicast
ones is not very easy, often against unicast ones.
For further details, see my presentation at APNIC32:
http://meetings.apnic.net/32/program/apops
How Path MTU Discovery Doesn't work
Masataka Ohta
> In IPv4 I can make tunneling just work nearly all of the time. So I have
> to munge a tcp mss header, or clear a df-bit, or fragment the
> encapsulated packet when all else fails, but at least the tools are
> there. And on the host, /proc/sys/net
FYI, IETF is trying to inhibit clearing DF bit explicitly with
draft-ietf-intarea-ipv4-id-update-05.txt
>> IPv4 datagram transit devices MUST NOT clear the DF bit.
which is now under the last call.
Masataka Ohta
From mysidia at gmail.com Mon Jun 4 01:20:32 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 4 Jun 2012 01:20:32 -0500
Subject: IPv6 day and tunnels
In-Reply-To: <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org>
References: <4FCC11B2.2090405@ttec.com>
<850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org>
Message-ID:
On 6/3/12, Jeroen Massar wrote:
> If one is so stupid to just block ICMP then one should also accept that one
> loses functionality.
ICMP tends to get blocked by firewalls by default; There are
legitimate reasons to block ICMP, esp w V6. Security device
manufacturers tend to indicate all the "lost functionality" is
optional functionality not required for a working device.
> If the people in the IETF would have decided to inline the headers that are
> ICMPv6 into the IPv6 header then there for sure would have been people who
> would have blocked the equivalent of PacketTooBig in there too. As long as
Over reliance on "PacketTooBig" is a source of the problem; the idea
that too large packets should be blindly generated under ordinary
circumstances, carried many hops, and dropped with an error returned a
potentially long distance that the sender in each direction is
expected to see and act upon, at the expense of high latency for both
peers, during initial connection establishment.
Routers don't always know when a packet is too big to reach their next
hop, especially in case of Broadcast traffic, so they don't know to
return a PacketTooBig error, especially in the case of L2 tunneling
PPPoE for example, there may be a L2 bridge on the network in between
routers with a lower MRU than either of the router's immediate links,
eg because PPP, 802.1p,q + MPLS labels, or other overhead are affixed
to Ethernet frames, somewhere on the switched path between routers.
The problem is not that "Tunneling is bad"; the problem is the IP
protocol has issues. The protocol should be designed so that there
will not be issues with tunnelling or different MRU Ethernet links.
The real solution is for reverse path MTU (MRU) information to be
discovered between L3 neighbors by L2 probing, and discovered MRU
exchanged using NDP, so routers know the lowest MRU on each directly
connected interface, then for the worst case reduction in reverse path
MTU to be included in the routing information passed via L3 routing
protocols both IGPs and EGPs to the next hop.
That is, no router should be allowed to enter a route into its
forwarding table, until the worst case reverse MTU is discovered, to
reach that network, with the exception, that a device may be
configured with a default route, and some directly connected networks.
The need for "Too Big" messages is then restricted to nodes connected
to terminal networks. And there should be no such thing as packet
fragmentation.
--
-JH
From jeroen at unfix.org Mon Jun 4 01:27:04 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Sun, 3 Jun 2012 23:27:04 -0700
Subject: IPv6 day and tunnels
In-Reply-To: <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp>
References: <4FCC11B2.2090405@ttec.com>
<4FCC4A6F.30907@necom830.hpcl.titech.ac.jp>
Message-ID: <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org>
On 3 Jun 2012, at 22:41, Masataka Ohta wrote:
> Joe Maimon wrote:
>
>> So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly?
>
> Completely wrongly.
Got a better solution? ;)
>> Or was the fix incorporating the breakage into the basic design?
>
> Yes.
>
> Because IPv6 requires ICMP packet too big generated against
> multicast, it is designed to cause ICMP implosions, which
> means ISPs must filter ICMP packet too big at least against
> multicast packets and, as distinguishing them from unicast
> ones is not very easy, often against unicast ones.
I do not see the problem that you are seeing, to adress the two issues in your slides:
- for multicast just set your max packetsize to 1280, no need for pmtu and thus this "implosion"
You think might happen. The sender controls the packetsize anyway and one does not want
to frag packets for multicast thus 1280 solves all of it.
- when doing IPv6 inside IPv6 the outer path has to be 1280+tunneloverhead, if it is not then
you need to use a tunneling protocol that knows how to frag and reassemble as is acting as a
medium with an mtu less than the minimum of 1280
Greets,
Jeroen
From jeroen at unfix.org Mon Jun 4 01:41:24 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Sun, 3 Jun 2012 23:41:24 -0700
Subject: IPv6 day and tunnels
In-Reply-To:
References: <4FCC11B2.2090405@ttec.com>
<850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org>
Message-ID: <394D107E-46FE-44F2-A784-B07725C7E489@unfix.org>
On 3 Jun 2012, at 23:20, Jimmy Hess wrote:
> On 6/3/12, Jeroen Massar wrote:
>> If one is so stupid to just block ICMP then one should also accept that one
>> loses functionality.
> ICMP tends to get blocked by firewalls by default
Which firewall product does that?
> ; There are
> legitimate reasons to block ICMP, esp w V6.
The moment one decides to block ICMPv6 you are likely breaking features of IPv6, chose wisely. There are several RFCs pointing out what one could and what one Must never block. Packet Too Big is a very well known one that one should not block.
If you decide to block anyway then well, your problem that your network breaks.
> Security device
> manufacturers tend to indicate all the "lost functionality" is
> optional functionality not required for a working device.
I suggest that you vote with your money and chose a different vendor if they shove that through your throat. Upgrading braincells is another option though ;)
>> If the people in the IETF would have decided to inline the headers that are
>> ICMPv6 into the IPv6 header then there for sure would have been people who
>> would have blocked the equivalent of PacketTooBig in there too. As long as
>
> Over reliance on "PacketTooBig" is a source of the problem; the idea
> that too large packets should be blindly generated under ordinary
> circumstances, carried many hops, and dropped with an error returned a
> potentially long distance that the sender in each direction is
> expected to see and act upon, at the expense of high latency for both
> peers, during initial connection establishment.
High latency? You do realize that it is only one roundtrip max that might happen and that there is no shorter way to inform your side of this situation?
> Routers don't always know when a packet is too big to reach their next
> hop, especially in case of Broadcast traffic,
You do realize that IPv6 does not have the concept of broadcast do you?! ;)
There is only: unicast, multicast and anycast
(and anycast is just unicast as it is a routing trick)
> so they don't know to
> return a PacketTooBig error, especially in the case of L2 tunneling
> PPPoE for example, there may be a L2 bridge on the network in between
> routers with a lower MRU than either of the router's immediate links,
> eg because PPP, 802.1p,q + MPLS labels, or other overhead are affixed
> to Ethernet frames, somewhere on the switched path between routers.
If you have a broken L2 network there is nothing that an L3 protocol can do about it.
Please properly configure it, stuff tend to work better that way.
> The problem is not that "Tunneling is bad"; the problem is the IP
> protocol has issues. The protocol should be designed so that there
> will not be issues with tunnelling or different MRU Ethernet links.
There is no issue as long as you properly respond with PtB and process them when received.
If your medium is <1280 then your medium has to solve the fragging of packets.
> The real solution is for reverse path MTU (MRU) information to be
> discovered between L3 neighbors by L2 probing, and discovered MRU
> exchanged using NDP, so routers know the lowest MRU on each directly
> connected interface, then for the worst case reduction in reverse path
> MTU to be included in the routing information passed via L3 routing
> protocols both IGPs and EGPs to the next hop.
You do realize that NDP only works on the local link and not further?! ;)
Also, carrying MTU and full routing info to end hosts is definitely not something a lot of operators would like to do let alone see in their networks. Similar to you not wanting ICMP in your network even though that is the agreed upon standard.
> That is, no router should be allowed to enter a route into its
> forwarding table, until the worst case reverse MTU is discovered, to
> reach that network, with the exception, that a device may be
> configured with a default route, and some directly connected networks.
If you want this in your network just configure it everywhere to 1280 and then process and answer PtBs on the edge. Your network, your problem that you will never use jumbo frames.
> The need for "Too Big" messages is then restricted to nodes connected
> to terminal networks. And there should be no such thing as packet
> fragmentation.
The fun thing is though that this Internet thing is quite a bit larger than your imaginary network...
Greets,
Jeroen
From owen at delong.com Mon Jun 4 02:01:34 2012
From: owen at delong.com (Owen DeLong)
Date: Mon, 4 Jun 2012 00:01:34 -0700
Subject: IPv6 day and tunnels
In-Reply-To:
References: <4FCC11B2.2090405@ttec.com>
<850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org>
Message-ID:
On Jun 3, 2012, at 11:20 PM, Jimmy Hess wrote:
> On 6/3/12, Jeroen Massar wrote:
>> If one is so stupid to just block ICMP then one should also accept that one
>> loses functionality.
> ICMP tends to get blocked by firewalls by default; There are
> legitimate reasons to block ICMP, esp w V6. Security device
> manufacturers tend to indicate all the "lost functionality" is
> optional functionality not required for a working device.
>
If you feel the need to block ICMP (I'm not convinced this is an actual need),
then you should do so very selectively in IPv6.
Blocking packet too big messages, especially is definitely harmful in IPv6 and
PMTU-D is _NOT_ optional functionality.
Any firewall/security device manufacturer that says it is will not get any
business from me (or anyone else who considers their requirements
properly before purchasing).
>> If the people in the IETF would have decided to inline the headers that are
>> ICMPv6 into the IPv6 header then there for sure would have been people who
>> would have blocked the equivalent of PacketTooBig in there too. As long as
>
> Over reliance on "PacketTooBig" is a source of the problem; the idea
> that too large packets should be blindly generated under ordinary
> circumstances, carried many hops, and dropped with an error returned a
> potentially long distance that the sender in each direction is
> expected to see and act upon, at the expense of high latency for both
> peers, during initial connection establishment.
>
Actually, this generally will NOT affect initial connection establishment and
due to slow start usually adds a very small amount of latency about 3-5kb
into the conversation.
> Routers don't always know when a packet is too big to reach their next
> hop, especially in case of Broadcast traffic, so they don't know to
> return a PacketTooBig error, especially in the case of L2 tunneling
> PPPoE for example, there may be a L2 bridge on the network in between
> routers with a lower MRU than either of the router's immediate links,
> eg because PPP, 802.1p,q + MPLS labels, or other overhead are affixed
> to Ethernet frames, somewhere on the switched path between routers.
That is a misconfiguration of the routers. Any routers in such a circumstance
need their interface configured for the lower MTU or things are going to break
with or without ICMP Packet Too Big messages because even if you didn't
have the DF bit, the router has no way to know to fragment the packet.
An L2 device should not be fragmenting L3 packets.
> The problem is not that "Tunneling is bad"; the problem is the IP
> protocol has issues. The protocol should be designed so that there
> will not be issues with tunnelling or different MRU Ethernet links.
And there are not issues so long as things are configured correctly.
Misconfiguration will cause issues no matter how well the protocol
is designed. The problem you are describing so far is not a problem
with the protocol, it is a problem with misconfigured devices.
> The real solution is for reverse path MTU (MRU) information to be
> discovered between L3 neighbors by L2 probing, and discovered MRU
> exchanged using NDP, so routers know the lowest MRU on each directly
> connected interface, then for the worst case reduction in reverse path
> MTU to be included in the routing information passed via L3 routing
> protocols both IGPs and EGPs to the next hop.
This could compensate for some amount of misconfiguration, but you're
adding a lot of overhead and a whole bunch of layering violations in
order to do it. I think it would be much easier to just fix the configuration
errors.
> That is, no router should be allowed to enter a route into its
> forwarding table, until the worst case reverse MTU is discovered, to
> reach that network, with the exception, that a device may be
> configured with a default route, and some directly connected networks.
I don't see how this would no cause more problems than you claim it
will solve.
> The need for "Too Big" messages is then restricted to nodes connected
> to terminal networks. And there should be no such thing as packet
> fragmentation.
There should be no such thing as packet fragmentation in the current
protocol. What is needed is for people to simply configure things
correctly and allow PTB messages to pass as designed.
Owen
From mhuff at ox.com Mon Jun 4 05:38:55 2012
From: mhuff at ox.com (Matthew Huff)
Date: Mon, 4 Jun 2012 06:38:55 -0400
Subject: IPv6 day and tunnels
In-Reply-To:
References: <4FCC11B2.2090405@ttec.com>
<850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org>
Message-ID: <483E6B0272B0284BA86D7596C40D29F901928BC8AB18@PUR-EXCH07.ox.com>
>> An L2 device should not be fragmenting L3 packets.
Layer 2 fragmentation used (20+ years ago) to be a common thing with bridged topologies like token-ring to Ethernet source-routing. Obviously, no so much anymore (at least I hope not), but it can and does happen.
I think part of the problem is that ISPs, CDN, hosting companies, etc. have assumed IPv6 is just IPv4 with longer addresses and haven't spent the time learning the differences like what was pointed out that ICMPv6 is a required protocol for IPv6 to work correctly. MTU issues are an annoyance with IPv4 but are a brokenness with IPv6. Knowledge with come, but it may take a bit of beating over the head for a while.
From stefan at nordu.net Mon Jun 4 05:46:36 2012
From: stefan at nordu.net (=?ISO-8859-1?Q?Stefan_Listr=F6m?=)
Date: Mon, 04 Jun 2012 12:46:36 +0200
Subject: NOC presentations
Message-ID: <4FCC920C.3070805@nordu.net>
Hi all,
In TF-NOC we have been collecting information about NOCs for some time
now[1]. Most of the NOCs are from research and educational organizations
and we think it would also be very interesting to get the same kind of
information from commercial NOCs. I understand that many commercial
companies might not be able to share this information, but I thought it
might be worth asking.
If you would like to share information about your NOC please check out
our presentation template[2] for inspiration and let me know.
Even if you are not able to share information about your NOC the
information we have gathered will hopefully still be interesting for you.
[1] http://www.terena.org/activities/tf-noc/nocs.html
[2] http://www.terena.org/activities/tf-noc/TF-NOC-flashpresentation-v2.ppt
--
Best regards
Stefan Listr?m
From mohta at necom830.hpcl.titech.ac.jp Mon Jun 4 08:36:10 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Mon, 04 Jun 2012 22:36:10 +0900
Subject: IPv6 day and tunnels
In-Reply-To: <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org>
References: <4FCC11B2.2090405@ttec.com>
<4FCC4A6F.30907@necom830.hpcl.titech.ac.jp>
<25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org>
Message-ID: <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp>
Jeroen Massar wrote:
>>> So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly?
>>
>> Completely wrongly.
>
> Got a better solution? ;)
IPv4 without PMTUD, of course.
>> Because IPv6 requires ICMP packet too big generated against
>> multicast, it is designed to cause ICMP implosions, which
>> means ISPs must filter ICMP packet too big at least against
>> multicast packets and, as distinguishing them from unicast
>> ones is not very easy, often against unicast ones.
>
> I do not see the problem that you are seeing, to adress the two
> issues in your slides:
> - for multicast just set your max packetsize to 1280, no
> need for pmtu and thus this "implosion"
It is a sender of a multicast packet, not you as some ISP,
who set max packet size to 1280B or 1500B.
You can do nothing against a sender who consciously (not
necessarily maliciously) set it to 1500B.
The only protection is not to generate packet too big and
to block packet too big at least against multicast packets.
If you don't want to inspect packets so deeply (beyond first
64B, for example), packet too big against unicast packets
are also blocked.
That you don't enable multicast in your network does not
mean you have nothing to do with packet too big against
multicast, because you may be on a path of returning ICMPs.
That is, you should still block them.
> You think might happen. The sender controls the packetsize
> anyway and one does not want
> to frag packets for multicast thus 1280 solves all of it.
That's what I said in IETF IPv6 WG more than 10 years ago, but
all the other WG members insisted on having multicast PMTUD,
ignoring the so obvious problem of packet implosions.
Thus, RFC2463 requires:
Sending a Packet Too Big Message makes an exception to one
of the rules of when to send an ICMPv6 error message, in that
unlike other messages, it is sent in response to a packet
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
received with an IPv6 multicast destination address, or a linklayer
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
multicast or link-layer broadcast address.
They have not yet obsoleted the feature.
So, you should assume some, if not all, of them still insist
on using multicast PMTUD to make multicast packet size larger
than 1280B.
In addition, there should be malicious guys.
> - when doing IPv6 inside IPv6 the outer path has to be
> 1280+tunneloverhead, if it is not then
Because PMTUD is not expected to work, you must assume MTU
of outer path is 1280B, as is specified "simply restrict
itself to sending packets no larger than 1280 octets" in
RFC2460.
> you need to use a tunneling protocol that knows how to
> frag and reassemble as is acting as a
> medium with an mtu less than the minimum of 1280
That's my point in my second last slide.
Considering that many inner packet will be just 1280B long,
many packets will be fragmented, as a result of stupid attempt
to make multicast PMTUD work, unless you violate RFC2460
to blindly send packets a little larger than 1280B.
Masataka Ohta
From jfesler at yahoo-inc.com Mon Jun 4 08:50:58 2012
From: jfesler at yahoo-inc.com (Jason Fesler)
Date: Mon, 4 Jun 2012 06:50:58 -0700
Subject: test-ipv6.com / omgipv6day.com down
Message-ID: <74F38EF5-6B3A-4970-A72F-C0B29A483D15@yahoo-inc.com>
I know a lot of people are using / pointing to test-ipv6.com . The hardware picked a bad week to quit sniffing glue.
I"ll be working on trying to get it back up today, I need to source hardware. Also looking at borrowing a VM for short term.
(speaking only for @test-ipv6.com, not for $employer - my personal mail address is down too).
From jeroen at unfix.org Mon Jun 4 09:07:52 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Mon, 4 Jun 2012 07:07:52 -0700
Subject: IPv6 day and tunnels
In-Reply-To: <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp>
References: <4FCC11B2.2090405@ttec.com>
<4FCC4A6F.30907@necom830.hpcl.titech.ac.jp>
<25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org>
<4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp>
Message-ID: <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org>
On 4 Jun 2012, at 06:36, Masataka Ohta wrote:
> Jeroen Massar wrote:
>
>>>> So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly?
>>>
>>> Completely wrongly.
>>
>> Got a better solution? ;)
>
> IPv4 without PMTUD, of course.
We are (afaik) discussing IPv6 in this thread, I assume you typo'd here ;)
>>> Because IPv6 requires ICMP packet too big generated against
>>> multicast, it is designed to cause ICMP implosions, which
>>> means ISPs must filter ICMP packet too big at least against
>>> multicast packets and, as distinguishing them from unicast
>>> ones is not very easy, often against unicast ones.
>>
>> I do not see the problem that you are seeing, to adress the two
>> issues in your slides:
>> - for multicast just set your max packetsize to 1280, no
>> need for pmtu and thus this "implosion"
>
> It is a sender of a multicast packet, not you as some ISP,
> who set max packet size to 1280B or 1500B.
If a customer already miraculously has the rare capability of sending multicast packets in the rare case that a network is multicast enabled then they will also have been told to use a max packet size of 1280 to avoid any issues when it is expected that some endpoint might have that max MTU.
I really cannot see the problem with this as multicast networks tend to be rare and very much closed. Heck, for that matter the m6bone is currently pretty much in a dead state for quite a while already.... :(
> You can do nothing against a sender who consciously (not
> necessarily maliciously) set it to 1500B.
Of course you can, the first hop into your network can generate a single PtB and presto the issue becomes a problem of the sender. As the sender's intention is likely to reach folks they will adhere to that advice too instead of just sending packets which get rejected at the first hop.
> The only protection is not to generate packet too big and
> to block packet too big at least against multicast packets.
No need, as above, reject and send PtB and all is fine.
> If you don't want to inspect packets so deeply (beyond first
> 64B, for example), packet too big against unicast packets
> are also blocked.
Routing (forwarding packets) is in no way "expection".
> That you don't enable multicast in your network does not
> mean you have nothing to do with packet too big against
> multicast, because you may be on a path of returning ICMPs.
> That is, you should still block them.
Blocking returning ICMPv6 PtB where you are looking at the original packet which is echod inside the data of the ICMPv6 packet would indeed require one to look quite deep, but if one is so determined to firewall them well, then you would have to indeed.
I do not see a reason to do so though. Please note that the src/dst of the packet itself is unicast even if the PtB will be for a multicast packet.
I guess one should not be so scared of ICMP, there are easier ways to overload a network. Proper BCP38 goes a long way.
>> You think might happen. The sender controls the packetsize
>> anyway and one does not want
>> to frag packets for multicast thus 1280 solves all of it.
>
> That's what I said in IETF IPv6 WG more than 10 years ago, but
> all the other WG members insisted on having multicast PMTUD,
> ignoring the so obvious problem of packet implosions.
They did not ignore you, they realized that not everybody has the same requirements. With the current spec you can go your way and break pMTU requiring manual 1280 settings, while other networks can use pMTU in their networks. Everbody wins.
> So, you should assume some, if not all, of them still insist
> on using multicast PMTUD to make multicast packet size larger
> than 1280B.
As networks become more and more jumbo frame enabled, what exactly is the problem with this?
> In addition, there should be malicious guys.
>
>> - when doing IPv6 inside IPv6 the outer path has to be
>> 1280+tunneloverhead, if it is not then
>
> Because PMTUD is not expected to work,
You assume it does not work, but as long as per the spec people do not filter it, it works.
> you must assume MTU
> of outer path is 1280B, as is specified "simply restrict
> itself to sending packets no larger than 1280 octets" in
> RFC2460.
While for multicast enabled networks that might hit the minimum MTU this might be true-ish, it does not make it universally true.
>> you need to use a tunneling protocol that knows how to
>> frag and reassemble as is acting as a
>> medium with an mtu less than the minimum of 1280
>
> That's my point in my second last slide.
Then you word it wrongly. It is not the problem of IPv6 that you chose to layer it inside so many stacks that the underlying medium cannot transport packets bigger as 1280, that medium has to take care of it.
> Considering that many inner packet will be just 1280B long,
> many packets will be fragmented, as a result of stupid attempt
> to make multicast PMTUD work, unless you violate RFC2460
> to blindly send packets a little larger than 1280B.
Your statement only works when:
- you chose a medium unable to send packets with a minimum of 1280
Which thus makes the medium IPv6 incapable, the mediums issue to frag
- someone filters ICMP PtB even though one should not
- when in the rare case with the above someone actually uses interdomain multicast
I hope you see how much of a non-issue this thus is.
Please fix your network instead, kthx.
Greets,
Jeroen
From jeroen at unfix.org Mon Jun 4 09:09:35 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Mon, 4 Jun 2012 07:09:35 -0700
Subject: test-ipv6.com / omgipv6day.com down
In-Reply-To: <74F38EF5-6B3A-4970-A72F-C0B29A483D15@yahoo-inc.com>
References: <74F38EF5-6B3A-4970-A72F-C0B29A483D15@yahoo-inc.com>
Message-ID: <12BA1049-475C-4A77-BEF0-A490A1426179@unfix.org>
On 4 Jun 2012, at 06:50, Jason Fesler wrote:
> I know a lot of people are using / pointing to test-ipv6.com . The hardware picked a bad week to quit sniffing glue.
You got a bunch of mirrors for it right? Should not be to tricky to get someone to let their act as the real thing for a bit.
Greets,
Jeroen
From jmaslak at antelope.net Mon Jun 4 09:16:32 2012
From: jmaslak at antelope.net (Joel Maslak)
Date: Mon, 4 Jun 2012 08:16:32 -0600
Subject: IPv6 day and tunnels
In-Reply-To:
References: <4FCC11B2.2090405@ttec.com>
<850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org>
Message-ID: <248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net>
On Jun 4, 2012, at 1:01 AM, Owen DeLong wrote:
> Any firewall/security device manufacturer that says it is will not get any
> business from me (or anyone else who considers their requirements
> properly before purchasing).
Unfortunately many technology people seem to have the idea, "If I don't understand it, it's a hacker" when it comes to network traffic. And often they don't understand ICMP (or at least PMTU). So anything not understood gets blocked. Then there is the Law of HTTP...
The Law of HTTP is pretty simple: Anything that isn't required for *ALL* HTTP connections on day one of protocol implementation will never be able to be used universally.
This includes, sadly, PMTU. If reaching all possible endpoints is important to your application, you better do it via HTTP and better not require PMTU. It's also why protocols typically can't be extended today at any layer other than the "HTTP" layer.
As for the IETF trying to not have people reset DF...good luck with that one...besides, I think there is more broken ICMP handling than there are paths that would allow a segment to bounce around for 120 seconds...
From jared at puck.nether.net Mon Jun 4 09:31:28 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 4 Jun 2012 10:31:28 -0400
Subject: IPv6 day and tunnels
In-Reply-To: <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org>
References: <4FCC11B2.2090405@ttec.com>
<4FCC4A6F.30907@necom830.hpcl.titech.ac.jp>
<25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org>
<4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp>
<530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org>
Message-ID: <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net>
On Jun 4, 2012, at 10:07 AM, Jeroen Massar wrote:
> On 4 Jun 2012, at 06:36, Masataka Ohta wrote:
>
>> Jeroen Massar wrote:
>>
>>>>> So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly?
>>>>
>>>> Completely wrongly.
>>>
>>> Got a better solution? ;)
>>
>> IPv4 without PMTUD, of course.
>
> We are (afaik) discussing IPv6 in this thread, I assume you typo'd here ;)
He is comparing & contrasting with the behavior of IPv4 v IPv6.
If your PMTU is broken for v4 because people do wholesale blocks of ICMP, there is a chance they will have the same problem with wholesale blocks of ICMPv6 packets.
The interesting thing about IPv6 is it's "just close enough" to IPv4 in many ways that people don't realize all the technical details. People are still getting it wrong with IPv4 today, they will repeat their same mistakes in IPv6 as well.
-
I've observed that if you avoid providers that rely upon tunnels, you can sometimes observe significant performance improvements in IPv6 nitrates. Those that are tunneling are likely to take a software path at one end, whereas native (or native-like/6PE) tends to not see this behavior. Those doing native tend to have more experience debugging it as well as they already committed business resources to it.
- Jared
From Fred.L.Templin at boeing.com Mon Jun 4 09:39:58 2012
From: Fred.L.Templin at boeing.com (Templin, Fred L)
Date: Mon, 4 Jun 2012 07:39:58 -0700
Subject: IPv6 day and tunnels
In-Reply-To: <248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net>
References: <4FCC11B2.2090405@ttec.com>
<850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org>
<248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net>
Message-ID:
Hi,
There was quite a bit discussion on IPv6 PMTUD on the v6ops
list within the past couple of weeks. Studies have shown
that PTB messages can be dropped due to filtering even for
ICMPv6. There was also concern for the one (or more) RTTs
required for PMTUD to work, and for dealing with bogus
PTB messages.
The concerns were explicitly linked to IPv6 tunnels, so
I drafted a proposed solution:
https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/
In this proposal the tunnel ingress performs the following
treatment of packets of various sizes:
1) For IPv6 packets no larger than 1280, admit the packet
into the tunnel w/o fragmentation. Assumption is that
all IPv6 links have to support a 1280 MinMTU, so the
packet will get through.
2) For IPv6 packets larger than 1500, admit the packet
into the tunnel w/o fragmentation. Assumption is that
the sender would only send a 1501+ packet if it has
some way of policing the PMTU on its own, e.g. through
the use of RC4821.
3) For IPv6 packets between 1281-1500, break the packet
into two (roughly) equal-sized pieces and admit each
piece into the tunnel. (In other words, intentionally
violate the IPv6 deprecation of router fragmentation.)
Assumption is that the final destination can reassemble
at least 1500, and that the 32-bit Identification value
inserted by the tunnel provides sufficient assurance
against reassembly mis-associations.
I presume no one here would object to clauses 1) and 2).
Clause 3) is obviously a bit more controversial - but,
what harm would it cause from an operational standpoint?
Thanks - Fred
fred.l.templin at boeing.com
From jmaimon at ttec.com Mon Jun 4 10:09:27 2012
From: jmaimon at ttec.com (Joe Maimon)
Date: Mon, 04 Jun 2012 11:09:27 -0400
Subject: IPv6 day and tunnels
In-Reply-To:
References: <4FCC11B2.2090405@ttec.com>
<850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org>
Message-ID: <4FCCCFA7.5070709@ttec.com>
Owen DeLong wrote:
>
> There should be no such thing as packet fragmentation in the current
> protocol. What is needed is for people to simply configure things
> correctly and allow PTB messages to pass as designed.
>
> Owen
You are absolutely correct. Are you talking about IPv4 or IPv6?
Joe
From jfesler at yahoo-inc.com Mon Jun 4 10:13:17 2012
From: jfesler at yahoo-inc.com (Jason Fesler)
Date: Mon, 4 Jun 2012 08:13:17 -0700
Subject: test-ipv6.com / omgipv6day.com down
In-Reply-To: <12BA1049-475C-4A77-BEF0-A490A1426179@unfix.org>
References: <74F38EF5-6B3A-4970-A72F-C0B29A483D15@yahoo-inc.com>
<12BA1049-475C-4A77-BEF0-A490A1426179@unfix.org>
Message-ID: <62475C28-453B-4E0F-A184-7E9ABDF9769D@yahoo-inc.com>
On Jun 4, 2012, at 7:09 AM, Jeroen Massar wrote:
> You got a bunch of mirrors for it right? Should not be to tricky to get someone to let their act as the real thing for a bit.
I've got redirects up now to spread the load across VMs. For the next couple of days, I don't expect a single VM to handle the load.
Thanks to all who've sent me a response; and thanks to Host Virtual and to Network Design GmbH, for taking the immediate load.
Once we're stable, and I get my *official* day job requirements met for World IPV6 Launch, I"ll come back to getting the original gear replaced. I've got a couple hardware offers in (Alex, Mark, thank you), and this might just be the reason to flat out refresh the hardware if ixSystems has something suitable already built.
-jason
From jra at baylink.com Mon Jun 4 10:15:50 2012
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 4 Jun 2012 11:15:50 -0400 (EDT)
Subject: WaPo: SHODAN search engine exposes insecure SCADA
Message-ID: <8205966.7504.1338822950068.JavaMail.root@benjamin.baylink.com>
... among other things.
http://www.washingtonpost.com/investigations/cyber-search-engine-exposes-vulnerabilities/2012/06/03/gJQAIK9KCV_story.html
If the gov is worried about 'cyber'-attacks on critical infrastructure,
at least now we know what tool they can use to find the low hanging fruit.
As I asked once before (:-), any black-sunglasses types hanging around?
Don't answer; just go to work.
Cheers,
-- jra
--
Jay R. Ashworth Baylink jra at baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
From jeroen at unfix.org Mon Jun 4 10:26:37 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Mon, 04 Jun 2012 08:26:37 -0700
Subject: test-ipv6.com / omgipv6day.com down
In-Reply-To: <62475C28-453B-4E0F-A184-7E9ABDF9769D@yahoo-inc.com>
References: <74F38EF5-6B3A-4970-A72F-C0B29A483D15@yahoo-inc.com>
<12BA1049-475C-4A77-BEF0-A490A1426179@unfix.org>
<62475C28-453B-4E0F-A184-7E9ABDF9769D@yahoo-inc.com>
Message-ID: <4FCCD3AD.5000104@unfix.org>
On 2012-06-04 08:13, Jason Fesler wrote:
>
> On Jun 4, 2012, at 7:09 AM, Jeroen Massar wrote:
>
>> You got a bunch of mirrors for it right? Should not be to tricky to
>> get someone to let their act as the real thing for a bit.
>
> I've got redirects up now to spread the load across VMs. For the
> next couple of days, I don't expect a single VM to handle the load.
I am actually not expecting that much of the hype to come out, just like
last year it will easily be forgotten unless somebody is able to spin
that PR engine really really really hard.
> Thanks to all who've sent me a response; and thanks to Host Virtual
> and to Network Design GmbH, for taking the immediate load.
>
> Once we're stable, and I get my *official* day job requirements met
> for World IPV6 Launch, I"ll come back to getting the original gear
> replaced. I've got a couple hardware offers in (Alex, Mark, thank
> you), and this might just be the reason to flat out refresh the
> hardware if ixSystems has something suitable already built.
Awesome!
Greets,
Jeroen
From mohta at necom830.hpcl.titech.ac.jp Mon Jun 4 10:34:34 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Tue, 05 Jun 2012 00:34:34 +0900
Subject: IPv6 day and tunnels
In-Reply-To: <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org>
References: <4FCC11B2.2090405@ttec.com>
<4FCC4A6F.30907@necom830.hpcl.titech.ac.jp>
<25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org>
<4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp>
<530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org>
Message-ID: <4FCCD58A.4040801@necom830.hpcl.titech.ac.jp>
Jeroen Massar wrote:
>> IPv4 without PMTUD, of course.
>
> We are (afaik) discussing IPv6 in this thread,
That's your problem of insisting on very narrow solution
space, which is why you can find no solution and are
trying to ignore the problem.
>> It is a sender of a multicast packet, not you as some ISP,
>> who set max packet size to 1280B or 1500B.
>
> If a customer already miraculously has the rare capability
> of sending multicast packets in the rare case that a
> network is multicast enabled
That is the case IPv6 WG insisted on.
> then they will also have been told to use a max packet size
> of 1280 to avoid any issues when it is expected that some
> endpoint might have that max MTU.
Those who insisted on the case won't tell so nor do so.
> I really cannot see the problem with this
because you insist on IPv6.
>> You can do nothing against a sender who consciously (not
>> necessarily maliciously) set it to 1500B.
>
> Of course you can, the first hop into your network can
> generate a single PtB
I can, but I can't expect others will do so.
I, instead, know those who insisted on the case won't.
> No need, as above, reject and send PtB and all is fine.
As I wrote:
>> That you don't enable multicast in your network does not
>> mean you have nothing to do with packet too big against
>> multicast, because you may be on a path of returning ICMPs.
>> That is, you should still block them.
you are wrong.
>> If you don't want to inspect packets so deeply (beyond first
>> 64B, for example), packet too big against unicast packets
>> are also blocked.
>
> Routing (forwarding packets) is in no way "expection".
What?
> Blocking returning ICMPv6 PtB where you are looking at the
> original packet which is echod inside the data of the
> ICMPv6 packet would indeed require one to look quite deep,
> but if one is so determined to firewall them well, then
> you would have to indeed.
As I already filter packets required by RFC2463, why, do you
think, do I have to bother only to reduce performance?
> I do not see a reason to do so though. Please note that the
> src/dst of the packet itself is unicast even if the PtB
> will be for a multicast packet.
How can you ignore the implosion of unicast ICMP?
> They did not ignore you, they realized that not everybody
> has the same requirements. With the current spec you can
> go your way and break pMTU requiring manual 1280 settings,
> while other networks can use pMTU in their networks.Everbody wins.
What? Their networks? The Internet is interconnected.
>> So, you should assume some, if not all, of them still insist
>> on using multicast PMTUD to make multicast packet size larger
>> than 1280B.
>
> As networks become more and more jumbo frame enabled,
> what exactly is the problem with this?
That makes things worse.
It will promote people try to multicast with jumbo frames.
>> Because PMTUD is not expected to work,
>
> You assume it does not work, but as long as per the spec
> people do not filter it, it works.
Such operation leaves network vulnerable and should be corrected.
>> you must assume MTU
>> of outer path is 1280B, as is specified "simply restrict
>> itself to sending packets no larger than 1280 octets" in
>> RFC2460.
>
> While for multicast enabled networks that might hit the
> minimum MTU this might be true-ish, it does not make
> it universally true.
The Internet is interconnected.
>>> you need to use a tunneling protocol that knows how to
>>> frag and reassemble as is acting as a
>>> medium with an mtu less than the minimum of 1280
>>
>> That's my point in my second last slide.
>
> Then you word it wrongly. It is not the problem of IPv6
You should read RFC2473, an example in my slide.
> Please fix your network instead, kthx.
It is a problem of RFC2463 and networks of people who insist
on the current RFC2463 for multicast PMTUD.
If you want the problem disappear, change RFC2463.
Masataka Ohta
From rbf+nanog at panix.com Mon Jun 4 11:35:03 2012
From: rbf+nanog at panix.com (Brett Frankenberger)
Date: Mon, 4 Jun 2012 11:35:03 -0500
Subject: IPv6 day and tunnels
In-Reply-To:
References: <4FCC11B2.2090405@ttec.com>
<850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org>
<248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net>
Message-ID: <20120604163503.GA28331@panix.com>
On Mon, Jun 04, 2012 at 07:39:58AM -0700, Templin, Fred L wrote:
>
> https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/
>
> 3) For IPv6 packets between 1281-1500, break the packet
> into two (roughly) equal-sized pieces and admit each
> piece into the tunnel. (In other words, intentionally
> violate the IPv6 deprecation of router fragmentation.)
> Assumption is that the final destination can reassemble
> at least 1500, and that the 32-bit Identification value
> inserted by the tunnel provides sufficient assurance
> against reassembly mis-associations.
Fragmenting the outer packet, rather than the inner packet, gets around
the problem of router fragmentation of packets. The outer packet is a
new packet and there's nothing wrong with the originator of that packet
fragmenting it.
Of course, that forces reassembly on the other tunnel endpoint, rather
than on the ultimate end system, which might be problematic with some
endpoints and traffic volumes.
(With IPv4 in IPv4 tunnels, this is what I've always done. 1500 byte
MTU on the tunnel, fragment the outer packet, let the other end of the
tunnel do the reassembly. Not providing 1500 byte end-to-end (at least
with in the network I control) for IPv4 has proven to consume lots of
troubleshooting time; fragmenting the inner packet doesn't work unless
you ignore the DF bit that is typically set by TCP endpoints who want
to do PMTU discovery.)
> I presume no one here would object to clauses 1) and 2).
> Clause 3) is obviously a bit more controversial - but,
> what harm would it cause from an operational standpoint?
-- Brett
From Fred.L.Templin at boeing.com Mon Jun 4 12:19:01 2012
From: Fred.L.Templin at boeing.com (Templin, Fred L)
Date: Mon, 4 Jun 2012 10:19:01 -0700
Subject: IPv6 day and tunnels
In-Reply-To: <20120604163503.GA28331@panix.com>
References: <4FCC11B2.2090405@ttec.com>
<850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org>
<248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net>
<20120604163503.GA28331@panix.com>
Message-ID:
Hi Brett,
> -----Original Message-----
> From: Brett Frankenberger [mailto:rbf+nanog at panix.com]
> Sent: Monday, June 04, 2012 9:35 AM
> To: Templin, Fred L
> Cc: nanog at nanog.org
> Subject: Re: IPv6 day and tunnels
>
> On Mon, Jun 04, 2012 at 07:39:58AM -0700, Templin, Fred L wrote:
> >
> > https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/
> >
> > 3) For IPv6 packets between 1281-1500, break the packet
> > into two (roughly) equal-sized pieces and admit each
> > piece into the tunnel. (In other words, intentionally
> > violate the IPv6 deprecation of router fragmentation.)
> > Assumption is that the final destination can reassemble
> > at least 1500, and that the 32-bit Identification value
> > inserted by the tunnel provides sufficient assurance
> > against reassembly mis-associations.
>
> Fragmenting the outer packet, rather than the inner packet, gets around
> the problem of router fragmentation of packets. The outer packet is a
> new packet and there's nothing wrong with the originator of that packet
> fragmenting it.
>
> Of course, that forces reassembly on the other tunnel endpoint, rather
> than on the ultimate end system, which might be problematic with some
> endpoints and traffic volumes.
There are a number of issues with fragmenting the outer packet.
First, as you say, fragmenting the outer packet requires the
tunnel egress to perform reassembly. This may be difficult for
tunnel egresses that are configured on core routers. Also, when
IPv4 is used as the outer encapsulation layer, the 16-bit ID
field can result in reassembly errors at high data rates
[RFC4963]. Additionally, encapsulating a 1500 inner packet in
an outer IP header results in a 1500+ outer packet - and the
ingress has no way of knowing whether the egress is capable
of reassembling larger than 1500.
> (With IPv4 in IPv4 tunnels, this is what I've always done. 1500 byte
> MTU on the tunnel, fragment the outer packet, let the other end of the
> tunnel do the reassembly. Not providing 1500 byte end-to-end (at least
> with in the network I control) for IPv4 has proven to consume lots of
> troubleshooting time; fragmenting the inner packet doesn't work unless
> you ignore the DF bit that is typically set by TCP endpoints who want
> to do PMTU discovery.)
Ignoring the (explicit) DF bit for IPv4 and ignoring the
(implicit) DF bit for IPv6 is what I am suggesting.
Thanks - Fred
fred.l.templin at boeing.com
> > I presume no one here would object to clauses 1) and 2).
> > Clause 3) is obviously a bit more controversial - but,
> > what harm would it cause from an operational standpoint?
>
> -- Brett
From cb.list6 at gmail.com Mon Jun 4 12:26:15 2012
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Mon, 4 Jun 2012 10:26:15 -0700
Subject: IPv6 day and tunnels
In-Reply-To:
References: <4FCC11B2.2090405@ttec.com>
<850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org>
Message-ID:
On Sun, Jun 3, 2012 at 11:20 PM, Jimmy Hess wrote:
> On 6/3/12, Jeroen Massar wrote:
>> If one is so stupid to just block ICMP then one should also accept that one
>> loses functionality.
> ICMP tends to get blocked by firewalls by default; There are
> legitimate reasons to block ICMP, esp w V6. ? Security device
> manufacturers tend to indicate all the ?"lost functionality" ?is
> optional functionality ?not required for a working device.
>
In case security policy folks need a reference on what ICMPv6
functionality is required for IPv6 to work correctly, please reference
http://www.ietf.org/rfc/rfc4890.txt
CB
From mehmet at akcin.net Mon Jun 4 12:37:10 2012
From: mehmet at akcin.net (Mehmet Akcin)
Date: Mon, 4 Jun 2012 10:37:10 -0700
Subject: Questions about anycasting setup
In-Reply-To: <3C5E8697-8AFD-4A4B-9A4F-4AD48BE71F52@pch.net>
References:
<20120309081131.GC17726@h.detebe.org> <4F59C701.3090503@altadena.net>
<2763367C-26BA-4330-812E-C5898E154D14@gibbard.org>
<20120312082532.GD17726@h.detebe.org>
<3C5E8697-8AFD-4A4B-9A4F-4AD48BE71F52@pch.net>
Message-ID: <64E37D5B-33A8-43C7-A4CE-65151194FF84@akcin.net>
On Jun 3, 2012, at 2:11 PM, Bill Woodcock wrote:
> On Jun 3, 2012, at 12:35 PM, Anurag Bhatia wrote:
>> I tried doing anycasting with 3 nodes, and seems like it didn't worked well
>> at all. It seems like ISPs prefer their own or their customer route (which
>> is our transit provider) and there is almost no "short/local route" effect.
>
> Correct. That's why you need to use the same transit providers at each location.
It could be a nightmare to try to balance the traffic when you are using different providers.
You can go ahead and try using path prepending but you will always find some strangeness going on regardless.
As Bill mentioned using the same transit will help, especially if you use a transit provider that has some communities pre-defined which will allow you to automatically advertise or not (even geographically) , and path prepend by simply sending communities out , you will save lots of time.
Mehmet
From jon at smugmug.com Mon Jun 4 13:36:41 2012
From: jon at smugmug.com (jon Heise)
Date: Mon, 4 Jun 2012 11:36:41 -0700
Subject: bgp best practice question
Message-ID: <8E5EF620-F0CF-4288-9179-74D26AC5896F@smugmug.com>
I need to make one of our data centers internet accessible, i plan to advertise a /24 out of our existing /22 network block at our new site. My question is for our main datacenter, is it a better idea to continue to advertise the full /22 or advertise the remaining /23 and /24 networks ?
- Jon Heise
From brunner at nic-naa.net Mon Jun 4 13:49:37 2012
From: brunner at nic-naa.net (Eric Brunner-Williams)
Date: Mon, 04 Jun 2012 14:49:37 -0400
Subject: Wacky Weekend: The '.secure' gTLD
In-Reply-To: <1963017dea9e4841b7a83fb3cb3c9f86@mail.dessus.com>
References: <1963017dea9e4841b7a83fb3cb3c9f86@mail.dessus.com>
Message-ID: <4FCD0341.3040108@nic-naa.net>
On 6/4/12 12:30 AM, Keith Medcalf wrote:
> The greatest advantage of .SECURE is that it will help ensure that all the high-value targets are easy to find.
one of the rationalizations for imposing a dnssec mandatory to
implement requirement (by icann staff driven by dnssec evangelists) is
that all slds are benefit equally from the semantic.
restated, the value of protecting some bank.tld is indistinguishable
from protecting some junk.tld.
re-restated, no new tlds will offer no economic, or political,
incentives to attack mitigated by dnssec.
i differed from staff-and-dnssec-evangelists, and obviously lost.
see also all possible locations for registries already have native v6,
or can tunnel via avian carrier, another staff driven by ipv6
evangelists, who couldn't defer the v6 mandatory to implement
requirement until availability was no longer hypothetical, or
scheduled, for which difference again availed naught.
as a marketing message, sld use of .secure as a tld may be sufficient
to ensure that a sufficient density of high-value targets are indeed
slds of that tld. staff has not discovered a stability and security
requirement which is contra-indicated by such a common fate / point of
failure.
note also that the requirements for new tlds are significantly greater
than for the existing set, so whatever the .com operator does, it is
not driven by the contract compliance regime which contains either the
dnssec or v6 manditory upon delegation bogies.
-e
p.s. the usual -sec and -6 evangelicals can ... assert their inerrant
correctness as a matter of faith -- faith based policy seems to be the
norm.
From cgrundemann at gmail.com Mon Jun 4 13:55:01 2012
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Mon, 4 Jun 2012 12:55:01 -0600
Subject: bgp best practice question
In-Reply-To: <8E5EF620-F0CF-4288-9179-74D26AC5896F@smugmug.com>
References: <8E5EF620-F0CF-4288-9179-74D26AC5896F@smugmug.com>
Message-ID:
Depends on a few things, but the main questions are probably:
Are the data-centers connected on the backside (VPN, etc. - could the
new dc failover through the main dc)?
Yes - /22
Will that /24 ever be used in the main datacenter?
Yes - /22
$0.02
~Chris
On Mon, Jun 4, 2012 at 12:36 PM, jon Heise wrote:
> I need to make one of our data centers internet accessible, i plan to advertise a /24 out of our existing /22 network block at our new site. My question is for our main datacenter, is it a better idea to continue to advertise the full /22 or advertise the remaining /23 and /24 networks ?
>
> - Jon Heise
--
@ChrisGrundemann
http://chrisgrundemann.com
From EWieling at nyigc.com Mon Jun 4 13:58:16 2012
From: EWieling at nyigc.com (Eric Wieling)
Date: Mon, 4 Jun 2012 14:58:16 -0400
Subject: Cat Humor
Message-ID:
I'm not looking for help, just thought this was hilarious.
"Mark called in from XO he stated a tech was on site and found out that client used a CAT 6 cable instead of a CAT 5 cable and XO doesn't have a "connecting piece" for the CAT 6 cable. he stated if client gets a wire/cable guy out there to fix issue, XO can send out a tech to make sure they hook up everything correctly."
From saku at ytti.fi Mon Jun 4 14:02:34 2012
From: saku at ytti.fi (Saku Ytti)
Date: Mon, 4 Jun 2012 22:02:34 +0300
Subject: bgp best practice question
In-Reply-To: <8E5EF620-F0CF-4288-9179-74D26AC5896F@smugmug.com>
References: <8E5EF620-F0CF-4288-9179-74D26AC5896F@smugmug.com>
Message-ID: <20120604190234.GA6275@pob.ytti.fi>
On (2012-06-04 11:36 -0700), jon Heise wrote:
> I need to make one of our data centers internet accessible, i plan to advertise a /24 out of our existing /22 network block at our new site. My question is for our main datacenter, is it a better idea to continue to advertise the full /22 or advertise the remaining /23 and /24 networks ?
22 + 24. 23+24+24 makes no sense. There is no reason to fear getting extra
traffic, as traffic will plummet once hosts stop responding.
--
++ytti
From mohta at necom830.hpcl.titech.ac.jp Mon Jun 4 14:05:55 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Tue, 05 Jun 2012 04:05:55 +0900
Subject: IPv6 day and tunnels
In-Reply-To:
References: <4FCC11B2.2090405@ttec.com>
<850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org>
<248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net>
<20120604163503.GA28331@panix.com>
Message-ID: <4FCD0713.4030309@necom830.hpcl.titech.ac.jp>
Templin, Fred L wrote:
> Also, when
> IPv4 is used as the outer encapsulation layer, the 16-bit ID
> field can result in reassembly errors at high data rates
> [RFC4963].
As your proposal, too, gives up to have unique IDs, does that
matter?
Note that, with your draft, a route change between two
tunnels with same C may cause block corruption.
> Additionally, encapsulating a 1500 inner packet in
> an outer IP header results in a 1500+ outer packet - and the
> ingress has no way of knowing whether the egress is capable
> of reassembling larger than 1500.
Operators are responsible to have tunnel end points with
sufficient capabilities.
>
>> (With IPv4 in IPv4 tunnels, this is what I've always done. 1500 byte
>> MTU on the tunnel, fragment the outer packet, let the other end of the
>> tunnel do the reassembly. Not providing 1500 byte end-to-end (at least
>> with in the network I control) for IPv4 has proven to consume lots of
>> troubleshooting time; fragmenting the inner packet doesn't work unless
>> you ignore the DF bit that is typically set by TCP endpoints who want
>> to do PMTU discovery.)
>
> Ignoring the (explicit) DF bit for IPv4 and ignoring the
> (implicit) DF bit for IPv6 is what I am suggesting.
>
> Thanks - Fred
> fred.l.templin at boeing.com
>
>>> I presume no one here would object to clauses 1) and 2).
>>> Clause 3) is obviously a bit more controversial - but,
>>> what harm would it cause from an operational standpoint?
>>
>> -- Brett
>
>
>
From Fred.L.Templin at boeing.com Mon Jun 4 14:26:04 2012
From: Fred.L.Templin at boeing.com (Templin, Fred L)
Date: Mon, 4 Jun 2012 12:26:04 -0700
Subject: IPv6 day and tunnels
In-Reply-To: <4FCD0713.4030309@necom830.hpcl.titech.ac.jp>
References: <4FCC11B2.2090405@ttec.com>
<850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org>
<248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net>
<20120604163503.GA28331@panix.com>
<4FCD0713.4030309@necom830.hpcl.titech.ac.jp>
Message-ID:
> -----Original Message-----
> From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp]
> Sent: Monday, June 04, 2012 12:06 PM
> To: nanog at nanog.org
> Subject: Re: IPv6 day and tunnels
>
> Templin, Fred L wrote:
>
> > Also, when
> > IPv4 is used as the outer encapsulation layer, the 16-bit ID
> > field can result in reassembly errors at high data rates
> > [RFC4963].
>
> As your proposal, too, gives up to have unique IDs, does that
> matter?
This is taken care of by rate limiting at the tunnel
ingress. For IPv4-in-(foo) tunnels, rate limit is 11Mbps
which may be a bit limiting for some applications. For
IPv6-in-(foo) tunnels, rate limit is 733Gbps which
should be acceptable for most applications.
> Note that, with your draft, a route change between two
> tunnels with same C may cause block corruption.
There are several built-in mitigations for this. First,
the tunnel ingress does not assign Identification values
sequentially but rather "skips around" to avoid synchronizing
with some other node that is sending fragments to the same
(src,dst) pair. Secondly, the ingress chooses random fragment
sizes for the A and B portions of the packet so that the A
portion of packet 1 does not match up properly with the B
portion of packet 2 and hence will be dropped. Finally, even
if the A portion of packet 1 somehow matches up with the B
portion of packet 2 the Internet checksum provides an
additional line of defense.
> > Additionally, encapsulating a 1500 inner packet in
> > an outer IP header results in a 1500+ outer packet - and the
> > ingress has no way of knowing whether the egress is capable
> > of reassembling larger than 1500.
>
> Operators are responsible to have tunnel end points with
> sufficient capabilities.
It is recommended that IPv4 nodes be able to reassemble
as much as their connected interface MTUs. In the vast
majority of cases that means that the nodes should be
able to reassemble 1500. But, there is no assurance
of anything more!
Thanks - Fred
fred.l.templin at boeing.com
> >> (With IPv4 in IPv4 tunnels, this is what I've always done. 1500 byte
> >> MTU on the tunnel, fragment the outer packet, let the other end of the
> >> tunnel do the reassembly. Not providing 1500 byte end-to-end (at least
> >> with in the network I control) for IPv4 has proven to consume lots of
> >> troubleshooting time; fragmenting the inner packet doesn't work unless
> >> you ignore the DF bit that is typically set by TCP endpoints who want
> >> to do PMTU discovery.)
> >
> > Ignoring the (explicit) DF bit for IPv4 and ignoring the
> > (implicit) DF bit for IPv6 is what I am suggesting.
> >
> > Thanks - Fred
> > fred.l.templin at boeing.com
> >
> >>> I presume no one here would object to clauses 1) and 2).
> >>> Clause 3) is obviously a bit more controversial - but,
> >>> what harm would it cause from an operational standpoint?
> >>
> >> -- Brett
> >
> >
> >
>
From asullivan at dyn.com Mon Jun 4 14:28:10 2012
From: asullivan at dyn.com (Andrew Sullivan)
Date: Mon, 4 Jun 2012 15:28:10 -0400
Subject: Wacky Weekend: The '.secure' gTLD
In-Reply-To: <4FCD0341.3040108@nic-naa.net>
References: <1963017dea9e4841b7a83fb3cb3c9f86@mail.dessus.com>
<4FCD0341.3040108@nic-naa.net>
Message-ID: <20120604192809.GL614@dyn.com>
On Mon, Jun 04, 2012 at 02:49:37PM -0400, Eric Brunner-Williams wrote:
>
> one of the rationalizations for imposing a dnssec mandatory to
> implement requirement (by icann staff driven by dnssec evangelists) is
Well, I note that at least the .secure promoters haven't decided it's
a good idea:
; <<>> DiG 9.7.3-P3 <<>> @NS15.IXWEBHOSTING.COM -t DNSKEY dot-secure.co +dnssec +norec +noall +comment
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<
References: <4FCC11B2.2090405@ttec.com>
<850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org>
<248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net>
<20120604163503.GA28331@panix.com>
<4FCD0713.4030309@necom830.hpcl.titech.ac.jp>
Message-ID: <4FCD1596.7040800@necom830.hpcl.titech.ac.jp>
Templin, Fred L wrote:
>> As your proposal, too, gives up to have unique IDs, does that
>> matter?
>
> This is taken care of by rate limiting at the tunnel
No, I'm talking about:
Note that a possible conflict exists when IP fragmentation has
already been performed by a source host before the fragments arrive
at the tunnel ingress.
>> Note that, with your draft, a route change between two
>> tunnels with same C may cause block corruption.
>
> There are several built-in mitigations for this. First,
> the tunnel ingress does not assign Identification values
> sequentially but rather "skips around" to avoid synchronizing
> with some other node that is sending fragments to the same
I'm talking about two tunnels with same "skip" value.
> Secondly, the ingress chooses random fragment
> sizes for the A and B portions of the packet so that the A
> portion of packet 1 does not match up properly with the B
> portion of packet 2 and hence will be dropped.
You can do so with outer fragment, too. Moreover, it does not
have to be random but regular, which effectively extend ID
length.
> Finally, even
> if the A portion of packet 1 somehow matches up with the B
> portion of packet 2 the Internet checksum provides an
> additional line of defense.
Thus, don't insist on having unique IDs so much.
> It is recommended that IPv4 nodes be able to reassemble
> as much as their connected interface MTUs. In the vast
> majority of cases that means that the nodes should be
> able to reassemble 1500. But, there is no assurance
> of anything more!
I'm talking about not protocol recommendation but proper
operation.
Masataka Ohta
From brunner at nic-naa.net Mon Jun 4 15:21:08 2012
From: brunner at nic-naa.net (Eric Brunner-Williams)
Date: Mon, 04 Jun 2012 16:21:08 -0400
Subject: Wacky Weekend: The '.secure' gTLD
In-Reply-To: <20120604192809.GL614@dyn.com>
References: <1963017dea9e4841b7a83fb3cb3c9f86@mail.dessus.com>
<4FCD0341.3040108@nic-naa.net> <20120604192809.GL614@dyn.com>
Message-ID: <4FCD18B4.4020702@nic-naa.net>
On 6/4/12 3:28 PM, Andrew Sullivan wrote:
> Well, I note that at least the .secure promoters haven't decided it's
> a good idea:
the _known_ .secure-and-all-confusingly-similar-labels promoters.
the reveal is weeks away, followed by the joys of contention set
formation.
there may be more than one .secure application, and who knows, perhaps
a .sec in the bag, or a .cure, or a .seeker, or .sequre, or ...
however, yeah, the requirement bites at contract / delegation time, so
about a year in the future.
-e
From jeroen at unfix.org Mon Jun 4 15:31:15 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Mon, 04 Jun 2012 13:31:15 -0700
Subject: IPv6 day and tunnels
In-Reply-To: <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net>
References: <4FCC11B2.2090405@ttec.com>
<4FCC4A6F.30907@necom830.hpcl.titech.ac.jp>
<25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org>
<4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp>
<530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org>
<07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net>
Message-ID: <4FCD1B13.7080801@unfix.org>
On 2012-06-04 07:31, Jared Mauch wrote:
>
> On Jun 4, 2012, at 10:07 AM, Jeroen Massar wrote:
>
>> On 4 Jun 2012, at 06:36, Masataka Ohta
>> wrote:
>>
>>> Jeroen Massar wrote:
>>>
>>>>>> So IPv6 fixes the fragmentation and MTU issues of IPv4 by
>>>>>> how exactly?
>>>>>
>>>>> Completely wrongly.
>>>>
>>>> Got a better solution? ;)
>>>
>>> IPv4 without PMTUD, of course.
>>
>> We are (afaik) discussing IPv6 in this thread, I assume you typo'd
>> here ;)
>
> He is comparing & contrasting with the behavior of IPv4 v IPv6.
>
> If your PMTU is broken for v4 because people do wholesale blocks of
> ICMP, there is a chance they will have the same problem with
> wholesale blocks of ICMPv6 packets.
Yep, people who act stupid will remain stupid...
> The interesting thing about IPv6 is it's "just close enough" to IPv4
> in many ways that people don't realize all the technical details.
> People are still getting it wrong with IPv4 today, they will repeat
> their same mistakes in IPv6 as well.
IMHO they should not have to need to know about technical details.
But if one is configuring firewalls one should know what one is blocking
and things might break. If one does block PtB you should realize that
you are breaking connectivity in some cases and that that is your
problem to resolve, not that of other peoples. There are various 'secure
firewall' examples for people who are unable to think for themselves and
figure out what kind of firewalling is appropriate for their environment.
> I've observed that if you avoid providers that rely upon tunnels, you
> can sometimes observe significant performance improvements in IPv6
> nitrates. Those that are tunneling are likely to take a software
> path at one end, whereas native (or native-like/6PE) tends to not see
> this behavior. Those doing native tend to have more experience
> debugging it as well as they already committed business resources to
> it.
Tunnels therefor only should exist at the edge where native IPv6 cannot
be made possible without significant investments in hardware and or
other resources. Of course every tunnel should at one point in time be
replaced by native where possible, thus hopefully the folks planning
expenses and hardware upgrades have finally realized that they cannot
get around it any more and have put this "ipv6" feature on the list for
the next round of upgrades.
Note that software-based tunnels can be extremely quick nowadays too,
especially when given the fact that hardware can be so abundant. During
tests for sixxsd v4 I've been able to stuff 10GE through it with ease,
but the trick there is primarily also that we do not need to do an
"expensive" full ipv6 address lookup as we know how the addresses are
structured and thus instead of having to do a 128bit lookup we can
restrict that to a 12 bit lookup for those tunnels, which is just a
direct jump table, much cheaper than having generic silicon that needs
to do it for 128bits, then again that same trick of course would be so
much faster in hardware that is specifically built to apply that trick.
The trick is much faster than using the software tunnels that you would
normally find in eg a Linux or BSD kernel though, also because those
tunnels look up tunnels based on the IPv4 address, thus the full 32-bit
address space instead of using the knowledge that the 128bit one can be
reduced to the 12bits that we use. The advantage of knowing one's field
and being less generic ;)
Greets,
Jeroen
From hthakkar at ucsc.edu Mon Jun 4 15:45:44 2012
From: hthakkar at ucsc.edu (Hiten J. Thakkar)
Date: Mon, 04 Jun 2012 13:45:44 -0700
Subject: Recommendation for OOB management via IP
Message-ID: <4FCD1E78.1040302@ucsc.edu>
Hello!
My work place is looking for an OOB management over IP. We have
Lantronix KVM in our Datacenter with nearly 100% uptime and Lantronix
SLC-8/16/48 ports with 2 NICs deployed across various MDFs on campus and
remote locations (5). On our main campus we have a parallel net, but for
the remote locations we are looking to access Lantronix SLCs' via the
second NIC card using IP based solution. Can you kindly make
suggestions. I supremely appreciate your time and inputs in advance.
--
Thanks and regards,
Hiten J. Thakkar
From Fred.L.Templin at boeing.com Mon Jun 4 16:23:13 2012
From: Fred.L.Templin at boeing.com (Templin, Fred L)
Date: Mon, 4 Jun 2012 14:23:13 -0700
Subject: IPv6 day and tunnels
In-Reply-To: <4FCD1596.7040800@necom830.hpcl.titech.ac.jp>
References: <4FCC11B2.2090405@ttec.com>
<850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org>
<248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net>
<20120604163503.GA28331@panix.com>
<4FCD0713.4030309@necom830.hpcl.titech.ac.jp>
<4FCD1596.7040800@necom830.hpcl.titech.ac.jp>
Message-ID:
> -----Original Message-----
> From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp]
> Sent: Monday, June 04, 2012 1:08 PM
> To: Templin, Fred L; nanog at nanog.org
> Subject: Re: IPv6 day and tunnels
>
> Templin, Fred L wrote:
>
> >> As your proposal, too, gives up to have unique IDs, does that
> >> matter?
> >
> > This is taken care of by rate limiting at the tunnel
>
> No, I'm talking about:
>
> Note that a possible conflict exists when IP fragmentation has
> already been performed by a source host before the fragments arrive
> at the tunnel ingress.
>
> >> Note that, with your draft, a route change between two
> >> tunnels with same C may cause block corruption.
> >
> > There are several built-in mitigations for this. First,
> > the tunnel ingress does not assign Identification values
> > sequentially but rather "skips around" to avoid synchronizing
> > with some other node that is sending fragments to the same
>
> I'm talking about two tunnels with same "skip" value.
There are several factors to consider. First, each tunnel
ingress chooses its initial Identification value (or values)
randomly and independent of all other tunnel ingresses.
Secondly, the packet arrival rates at the various tunnel
ingresses are completely independent and in no way
correlated. So, while an occasional reassembly collision
is possible the 32-bit Identification value would make it
extremely rare. And the variability of packet arrivals
between the tunnel endpoints would make it such that a
string of consecutive collisions would never happen. So,
I'm not sure that a randomly-chosen "skip" value is even
necessary.
> > Secondly, the ingress chooses random fragment
> > sizes for the A and B portions of the packet so that the A
> > portion of packet 1 does not match up properly with the B
> > portion of packet 2 and hence will be dropped.
>
> You can do so with outer fragment, too. Moreover, it does not
> have to be random but regular, which effectively extend ID
> length.
Outer fragmentation cooks the tunnel egresses at high
data rates. End systems are expected and required to
reassemble on their own behalf.
> > Finally, even
> > if the A portion of packet 1 somehow matches up with the B
> > portion of packet 2 the Internet checksum provides an
> > additional line of defense.
>
> Thus, don't insist on having unique IDs so much.
Non-overlapping fragments are disallowed for IPv6, but
I think are still allowed for IPv4. So, IPv4 still needs
the unique IDs by virtue of rate limiting.
> > It is recommended that IPv4 nodes be able to reassemble
> > as much as their connected interface MTUs. In the vast
> > majority of cases that means that the nodes should be
> > able to reassemble 1500. But, there is no assurance
> > of anything more!
>
> I'm talking about not protocol recommendation but proper
> operation.
I don't see any operational guidance recommending the
tunnel ingress to configure an MRU of 1520 or larger.
Thanks - Fred
fred.l.templin at boeing.com
> Masataka Ohta
From jmaimon at ttec.com Mon Jun 4 16:26:27 2012
From: jmaimon at ttec.com (Joe Maimon)
Date: Mon, 04 Jun 2012 17:26:27 -0400
Subject: IPv6 day and tunnels
In-Reply-To: <4FCD1B13.7080801@unfix.org>
References: <4FCC11B2.2090405@ttec.com>
<4FCC4A6F.30907@necom830.hpcl.titech.ac.jp>
<25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org>
<4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp>
<530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org>
<07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net>
<4FCD1B13.7080801@unfix.org>
Message-ID: <4FCD2803.9070206@ttec.com>
Jeroen Massar wrote:
>
> Tunnels therefor only should exist at the edge where native IPv6 cannot
> be made possible without significant investments in hardware and or
> other resources. Of course every tunnel should at one point in time be
> replaced by native where possible, thus hopefully the folks planning
> expenses and hardware upgrades have finally realized that they cannot
> get around it any more and have put this "ipv6" feature on the list for
> the next round of upgrades.
IPv4 is pretty mature. Are there more or less tunnels on it?
Why do you think a maturing IPv6 means less tunnels as opposed to more?
Does IPv6 contain elegant solutions to all the issues one would resort
to tunnels with IPv4?
Does successful IPv6 deployment require obsoleting tunneling?
Fail.
Today, most people cant even get IPv6 without tunnels.
And tunnels are far from the only cause of MTU lower than what has
become the only valid MTU of 1500, thanks in no small part to people who
refuse to acknowledge operational reality and are quite satisfied with
the state of things once they find a "them" to blame it on.
I just want to know if we can expect IPv6 to devolve into 1280 standard
mtu and at what gigabit rates.
Joe
From Fred.L.Templin at boeing.com Mon Jun 4 16:33:21 2012
From: Fred.L.Templin at boeing.com (Templin, Fred L)
Date: Mon, 4 Jun 2012 14:33:21 -0700
Subject: IPv6 day and tunnels
In-Reply-To: <4FCD2803.9070206@ttec.com>
References: <4FCC11B2.2090405@ttec.com>
<4FCC4A6F.30907@necom830.hpcl.titech.ac.jp>
<25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org>
<4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp>
<530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org>
<07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net>
<4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com>
Message-ID:
> I just want to know if we can expect IPv6 to devolve into 1280 standard
> mtu and at what gigabit rates.
The vast majority of hosts will still expect 1500, so
we need to find a way to get them at least that much.
Fred
fred.l.templin at boeing.com
From jesler at sourcefire.com Mon Jun 4 16:35:24 2012
From: jesler at sourcefire.com (Joel Esler)
Date: Mon, 4 Jun 2012 17:35:24 -0400
Subject: Cat Humor
In-Reply-To:
References:
Message-ID: <8C9F98822F794DF2A761B7C881B6092C@sourcefire.com>
But a Cat 6 is one more isn't it?
http://www.youtube.com/watch?v=EbVKWCpNFhY
--
Joel Esler
On Monday, June 4, 2012 at 2:58 PM, Eric Wieling wrote:
>
> I'm not looking for help, just thought this was hilarious.
>
> "Mark called in from XO he stated a tech was on site and found out that client used a CAT 6 cable instead of a CAT 5 cable and XO doesn't have a "connecting piece" for the CAT 6 cable. he stated if client gets a wire/cable guy out there to fix issue, XO can send out a tech to make sure they hook up everything correctly."
From jeroen at unfix.org Mon Jun 4 16:47:00 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Mon, 04 Jun 2012 14:47:00 -0700
Subject: IPv6 day and tunnels
In-Reply-To: <4FCD2803.9070206@ttec.com>
References: <4FCC11B2.2090405@ttec.com>
<4FCC4A6F.30907@necom830.hpcl.titech.ac.jp>
<25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org>
<4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp>
<530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org>
<07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net>
<4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com>
Message-ID: <4FCD2CD4.30307@unfix.org>
On 2012-06-04 14:26, Joe Maimon wrote:
>
>
> Jeroen Massar wrote:
>
>>
>> Tunnels therefor only should exist at the edge where native IPv6 cannot
>> be made possible without significant investments in hardware and or
>> other resources. Of course every tunnel should at one point in time be
>> replaced by native where possible, thus hopefully the folks planning
>> expenses and hardware upgrades have finally realized that they cannot
>> get around it any more and have put this "ipv6" feature on the list for
>> the next round of upgrades.
>
>
> IPv4 is pretty mature. Are there more or less tunnels on it?
I would hazard to state that there are more IPv4 tunnels than IPv6
tunnels. This as "tunneling" is what most people simply call VPN and
there are large swaths of those.
> Why do you think a maturing IPv6 means less tunnels as opposed to more?
More native instead of tunneling IPv6 over IPv6. Note that tunneling in
this context is used for connecting locations that do not have IPv6 but
have IPv4, not for connecting ala VPN networks where you need to gain
access to a secured/secluded network.
If people want to use a tunnel for the purpose of a VPN, then they will,
be that IPv4 or IPv6 or both inside that tunnel.
> Does IPv6 contain elegant solutions to all the issues one would resort
> to tunnels with IPv4?
Instead of having a custom VPN protocol one can do IPSEC properly now as
there is no NAT that one has to get around. Microsoft's Direct Access
does this btw and is an excellent example of doing it correctly.
> Does successful IPv6 deployment require obsoleting tunneling?
No why should it? But note that "IPv6 tunnels" (not VPNs) are a
transition technique from IPv4 to IPv6 and thus should not remain around
forever, the transition will end somewhere, sometime, likely far away in
the future with the speed that IPv6 is being deployed ;)
> Fail.
>
> Today, most people cant even get IPv6 without tunnels.
In time that will change, that is simply transitional.
> And tunnels are far from the only cause of MTU lower than what has
> become the only valid MTU of 1500, thanks in no small part to people who
> refuse to acknowledge operational reality and are quite satisfied with
> the state of things once they find a "them" to blame it on.
>
> I just want to know if we can expect IPv6 to devolve into 1280 standard
> mtu and at what gigabit rates.
1280 is the minimum IPv6 MTU. If people allow pMTU to work, aka accept
and process ICMPv6 Packet-Too-Big messages everything will just work.
This whole thread is about people who cannot be bothered to know what
they are filtering and that they might just randomly block PtB as they
are doing with IPv4 today. Yes, in that case their network breaks if the
packets are suddenly larger than a link somewhere else, that is the same
as in IPv4 ;)
Greets,
Jeroen
From Fred.L.Templin at boeing.com Mon Jun 4 16:55:10 2012
From: Fred.L.Templin at boeing.com (Templin, Fred L)
Date: Mon, 4 Jun 2012 14:55:10 -0700
Subject: IPv6 day and tunnels
In-Reply-To: <4FCD2CD4.30307@unfix.org>
References: <4FCC11B2.2090405@ttec.com>
<4FCC4A6F.30907@necom830.hpcl.titech.ac.jp>
<25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org>
<4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp>
<530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org>
<07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net>
<4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com>
<4FCD2CD4.30307@unfix.org>
Message-ID:
> > I just want to know if we can expect IPv6 to devolve into 1280 standard
> > mtu and at what gigabit rates.
>
> 1280 is the minimum IPv6 MTU. If people allow pMTU to work, aka accept
> and process ICMPv6 Packet-Too-Big messages everything will just work.
>
> This whole thread is about people who cannot be bothered to know what
> they are filtering and that they might just randomly block PtB as they
> are doing with IPv4 today. Yes, in that case their network breaks if the
> packets are suddenly larger than a link somewhere else, that is the same
> as in IPv4 ;)
But, it is not necessarily the person that filters the PTBs
that suffers the breakage. It is the original source that
may be many IP hops further down the line, who would have
no way of knowing that the filtering is even happening.
Thanks - Fred
fred.l.templin at boeing.com
> Greets,
> Jeroen
From jeroen at unfix.org Mon Jun 4 17:04:48 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Mon, 04 Jun 2012 15:04:48 -0700
Subject: IPv6 day and tunnels
In-Reply-To:
References: <4FCC11B2.2090405@ttec.com>
<4FCC4A6F.30907@necom830.hpcl.titech.ac.jp>
<25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org>
<4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp>
<530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org>
<07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net>
<4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com>
<4FCD2CD4.30307@unfix.org>
Message-ID: <4FCD3100.5030201@unfix.org>
On 2012-06-04 14:55, Templin, Fred L wrote:
>>> I just want to know if we can expect IPv6 to devolve into 1280 standard
>>> mtu and at what gigabit rates.
>>
>> 1280 is the minimum IPv6 MTU. If people allow pMTU to work, aka accept
>> and process ICMPv6 Packet-Too-Big messages everything will just work.
>>
>> This whole thread is about people who cannot be bothered to know what
>> they are filtering and that they might just randomly block PtB as they
>> are doing with IPv4 today. Yes, in that case their network breaks if the
>> packets are suddenly larger than a link somewhere else, that is the same
>> as in IPv4 ;)
>
> But, it is not necessarily the person that filters the PTBs
> that suffers the breakage. It is the original source that
> may be many IP hops further down the line, who would have
> no way of knowing that the filtering is even happening.
It is not too tricky to figure that out actually:
$ tracepath6 www.nanog.org
1?: [LOCALHOST] 0.078ms pmtu 1500
1: 2620:0:6b0:a::1 0.540ms
1: 2620:0:6b0:a::1 1.124ms
2: ge-4-35.car2.Chicago2.Level3.net 56.557ms asymm 13
3: vl-52.edge4.Chicago2.Level3.net 57.501ms asymm 13
4: 2001:1890:1fff:310:192:205:37:149 61.910ms asymm 10
5: cgcil21crs.ipv6.att.net 92.067ms asymm 12
6: sffca21crs.ipv6.att.net 94.720ms asymm 12
7: cr81.sj2ca.ip.att.net 90.068ms asymm 12
8: sj2ca401me3.ipv6.att.net 90.605ms asymm 11
9: 2001:1890:c00:3a00::11fb:8591 89.888ms asymm 12
10: no reply
11: no reply
12: no reply
and you'll at least have a good guess where it happens.
Not something for non-techy users, but good enough hopefully for people
working in the various NOCs.
Now the tricky part is where to complain to get that fixed though ;)
Greets,
Jeroen
(tracepath6 is available on your favourite Linux, eg in the
iputils-tracepath package for Debian, for the various *BSD's one can use
scamper from: http://www.wand.net.nz/scamper/ )
From alex-lists-nanog at yuriev.com Mon Jun 4 17:08:47 2012
From: alex-lists-nanog at yuriev.com (alex-lists-nanog at yuriev.com)
Date: Mon, 4 Jun 2012 18:08:47 -0400
Subject: Google Public DNS contact
Message-ID: <20120604220847.GA16897@corp.zubrcom.net>
Hello,
If anyone has a contact in the Google Group that deals with Google's
Public DNS servers ( i.e. the 8.8.8.8/8.8.4.4 creatures ) could that person
kindly drop me an email off list?
I believe there might be an issue with some of the servers.
Thanks,
Alex
From owen at delong.com Mon Jun 4 17:08:02 2012
From: owen at delong.com (Owen DeLong)
Date: Mon, 4 Jun 2012 15:08:02 -0700
Subject: IPv6 day and tunnels
In-Reply-To: <4FCD2803.9070206@ttec.com>
References: <4FCC11B2.2090405@ttec.com>
<4FCC4A6F.30907@necom830.hpcl.titech.ac.jp>
<25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org>
<4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp>
<530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org>
<07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net>
<4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com>
Message-ID:
On Jun 4, 2012, at 2:26 PM, Joe Maimon wrote:
>
>
> Jeroen Massar wrote:
>
>>
>> Tunnels therefor only should exist at the edge where native IPv6 cannot
>> be made possible without significant investments in hardware and or
>> other resources. Of course every tunnel should at one point in time be
>> replaced by native where possible, thus hopefully the folks planning
>> expenses and hardware upgrades have finally realized that they cannot
>> get around it any more and have put this "ipv6" feature on the list for
>> the next round of upgrades.
>
>
> IPv4 is pretty mature. Are there more or less tunnels on it?
>
There are dramatically fewer IPv4 tunnels than IPv6 tunnels to the best of my knowledge.
> Why do you think a maturing IPv6 means less tunnels as opposed to more?
>
Because a maturing IPv6 eliminates many of the present day needs for IPv6 tunnels which
is to span IPv4-only areas of the network when connecting IPv6 end points.
> Does IPv6 contain elegant solutions to all the issues one would resort to tunnels with IPv4?
Many of the issues I would resort to tunnels for involve working around NAT, so, yes, IPv6
provides a much more elegant solution -- End-to-end addressing.
However, for some of the other cases, no, tunnels will remain valuable in IPv6. However, as
IPv6 end-to-end native connectivity becomes more prevalent, much of the current need for
IPv6 over IPv4 tunnels will become deprecated.
> Does successful IPv6 deployment require obsoleting tunneling?
No, it does not, but, it will naturally obsolete many of the tunnels which exist today.
> Fail.
>
What, exactly are you saying is a failure? The single word here even in context is
very ambiguous.
> Today, most people cant even get IPv6 without tunnels.
Anyone can get IPv6 without a tunnel if they are willing to bring a circuit to the right place.
As IPv6 gets more ubiquitously deployed, the number of right places will grow and the cost
of getting a circuit to one of them will thus decrease.
> And tunnels are far from the only cause of MTU lower than what has become the only valid MTU of 1500, thanks in no small part to people who refuse to acknowledge operational reality and are quite satisfied with the state of things once they find a "them" to blame it on.
Meh... Sour grapes really don't add anything useful to the discussion.
Breaking PMTU-D is bad. People should stop doing so.
Blocking PTB messages is bad in IPv4 and worse in IPv6.
This has been well known for many years. If you're breaking PMTU-D, then stop that. If not, then you're not part of them.
If you have a useful alternative solution to propose, put it forth and let's discuss the merits.
> I just want to know if we can expect IPv6 to devolve into 1280 standard mtu and at what gigabit rates.
I hope not. I hope that IPv6 will cause people to actually re-evaluate their behavior WRT PMTU-D and correct the actual problem. Working PMTU-D allows not only 1500, but also 1280, and 9000 and >9000 octet datagrams to be possible and segments that support <1500 work almost as well as segments that support jumbo frames. Where jumbo frames offer an end-to-end advantage, that advantage can be realized. Where there is a segment with a 1280 MTU, that can also work with a relatively small performance penalty.
Where PMTU-D is broken, nothing works unless the MTU end-to-end happens to coincide with the smallest MTU.
For links that carry tunnels and clear traffic, life gets interesting if one of them is the one with the smallest MTU regardless of the MTU value chosen.
Owen
>
>
> Joe
From nanog-post at rsuc.gweep.net Mon Jun 4 17:15:46 2012
From: nanog-post at rsuc.gweep.net (Joe Provo)
Date: Mon, 4 Jun 2012 18:15:46 -0400
Subject: Google Public DNS contact
In-Reply-To: <20120604220847.GA16897@corp.zubrcom.net>
References: <20120604220847.GA16897@corp.zubrcom.net>
Message-ID: <20120604221545.GA85819@gweep.net>
On Mon, Jun 04, 2012 at 06:08:47PM -0400, alex-lists-nanog at yuriev.com wrote:
> Hello,
>
> If anyone has a contact in the Google Group that deals with Google's
> Public DNS servers ( i.e. the 8.8.8.8/8.8.4.4 creatures ) could that person
> kindly drop me an email off list?
>
> I believe there might be an issue with some of the servers.
Have you already visited https://developers.google.com/speed/public-dns/
and contacted the public group mantioned? See also
https://developers.google.com/speed/public-dns/faq#support ...
--
RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG
From jmaimon at ttec.com Mon Jun 4 17:27:24 2012
From: jmaimon at ttec.com (Joe Maimon)
Date: Mon, 04 Jun 2012 18:27:24 -0400
Subject: IPv6 day and tunnels
In-Reply-To: <4FCD2CD4.30307@unfix.org>
References: <4FCC11B2.2090405@ttec.com>
<4FCC4A6F.30907@necom830.hpcl.titech.ac.jp>
<25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org>
<4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp>
<530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org>
<07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net>
<4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com>
<4FCD2CD4.30307@unfix.org>
Message-ID: <4FCD364C.5070001@ttec.com>
Jeroen Massar wrote:
> If people want to use a tunnel for the purpose of a VPN, then they will,
> be that IPv4 or IPv6 or both inside that tunnel.
>
> Instead of having a custom VPN protocol one can do IPSEC properly now as
> there is no NAT that one has to get around. Microsoft's Direct Access
> does this btw and is an excellent example of doing it correctly.
Microsoft has had this capability since win2k. I didnt see any
enterprises use it, even those who used their globally unique and routed
ipv4 /16 internally. NAT was not why they did not use it.
They did not use it externally, they did not use it internally.
In fact, most of them were involved in projects to switch to NAT internally.
Enterprises also happen not to be thrilled with the absence of NAT in IPv6.
Dont expect huge uptake there.
> No why should it? But note that "IPv6 tunnels" (not VPNs) are a
> transition technique from IPv4 to IPv6 and thus should not remain around
> forever, the transition will end somewhere, sometime, likely far away in
> the future with the speed that IPv6 is being deployed ;)
So VPN is the _only_ acceptable use of sub 1500 encapsulation?
>> Today, most people cant even get IPv6 without tunnels.
>
> In time that will change, that is simply transitional.
If turning it on with a tunnel breaks things, it wont make native
transition happen sooner.
>
> 1280 is the minimum IPv6 MTU. If people allow pMTU to work, aka accept
> and process ICMPv6 Packet-Too-Big messages everything will just work.
If things break with higher mtu's then 1280 but less then 1500, there
really is no reason at all not to use 1280, the efficiency difference is
trivial. And on the IPv4 internet, we generally cannot control what most
of the rest of the people on it do. Looks like we are not going to be
doing any better on the IPv6 internet.
>
> This whole thread is about people who cannot be bothered to know what
> they are filtering and that they might just randomly block PtB as they
> are doing with IPv4 today. Yes, in that case their network breaks if the
> packets are suddenly larger than a link somewhere else, that is the same
> as in IPv4 ;)
>
> Greets,
> Jeroen
>
This whole thread is all about how IPv6 has not improved any of the
issues that are well known with IPv4 and in many cases makes them worse.
This whole thread is all about showcasing how IPv6 makes them worse,
simply because it is designed with "this time they will do what we want"
mentality.
Joe
From jmaimon at ttec.com Mon Jun 4 17:34:31 2012
From: jmaimon at ttec.com (Joe Maimon)
Date: Mon, 04 Jun 2012 18:34:31 -0400
Subject: IPv6 day and tunnels
In-Reply-To:
References: <4FCC11B2.2090405@ttec.com>
<4FCC4A6F.30907@necom830.hpcl.titech.ac.jp>
<25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org>
<4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp>
<530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org>
<07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net>
<4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com>
Message-ID: <4FCD37F7.2050201@ttec.com>
Owen DeLong wrote:
>
>> Fail.
>>
>
> What, exactly are you saying is a failure? The single word here even in context is
> very ambiguous.
The failure is that even now, when tunnels are critical to transition, a
proper solution that improves on the IPv4 problems does not exist
And if tunnels do become less prevalent there will be even less impetus
than now to make things work better.
>
>> Today, most people cant even get IPv6 without tunnels.
>
> Anyone can get IPv6 without a tunnel if they are willing to bring a circuit to the right place.
Today most people cant even get IPv6 without tunnels, or without paying
excessively more for their internet connection, or without having their
pool of vendors shrink dramatically, sometimes to the point of none.
>
> Breaking PMTU-D is bad. People should stop doing so.
>
> Blocking PTB messages is bad in IPv4 and worse in IPv6.
It has always been bad and people have not stopped doing it. And
intentional blocking is not the sole cause of pmtud breaking.
>
> If you have a useful alternative solution to propose, put it forth and let's discuss the merits.
PMTU-d probing, as recently standardizes seems a more likely solution.
Having CPE capable of TCP mss adjustment on v6 is another one. Being
able to fragment when you want to is another good one as well.
> I hope not. I hope that IPv6 will cause people to actually re-evaluate their behavior WRT PMTU-D and correct the actual problem. Working PMTU-D allows not only 1500, but also 1280, and 9000 and>9000 octet datagrams to be possible and segments that support<1500 work almost as well as segments that support jumbo frames. Where jumbo frames offer an end-to-end advantage, that advantage can be realized. Where there is a segment with a 1280 MTU, that can also work with a relatively small performance penalty.
>
> Where PMTU-D is broken, nothing works unless the MTU end-to-end happens to coincide with the smallest MTU.
>
> For links that carry tunnels and clear traffic, life gets interesting if one of them is the one with the smallest MTU regardless of the MTU value chosen.
>
> Owen
>
I dont share your optimism that it will go any better this time around
than last. If it goes at all.
Joe
From Fred.L.Templin at boeing.com Mon Jun 4 17:43:54 2012
From: Fred.L.Templin at boeing.com (Templin, Fred L)
Date: Mon, 4 Jun 2012 15:43:54 -0700
Subject: IPv6 day and tunnels
In-Reply-To: <4FCD37F7.2050201@ttec.com>
References: <4FCC11B2.2090405@ttec.com>
<4FCC4A6F.30907@necom830.hpcl.titech.ac.jp>
<25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org>
<4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp>
<530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org>
<07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net>
<4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com>
<4FCD37F7.2050201@ttec.com>
Message-ID:
> PMTU-d probing, as recently standardizes seems a more likely solution.
> Having CPE capable of TCP mss adjustment on v6 is another one. Being
> able to fragment when you want to is another good one as well.
I'll take a) and c), but don't care so much for b).
About fragmenting, any tunnel ingress (VPNs included) can
do inner fragmentation today independently of all other
ingresses and with no changes necessary on the egress.
It's just that they need to take precautions to avoid
messing up the final destination's reassembly buffers.
Fred
fred.l.templin at boeing.com
From mjl at caida.org Mon Jun 4 17:49:01 2012
From: mjl at caida.org (Matthew Luckie)
Date: Mon, 04 Jun 2012 15:49:01 -0700
Subject: IPv6 evolution
Message-ID: <4FCD3B5D.4050801@caida.org>
IPv6 paths that are the same as an IPv4-level path are correlated with
better IPv6 performance according to: "Assessing IPv6 Through Web
Access - A Measurement Study and Its Findings"
http://repository.upenn.edu/ese_papers/602/
At the Feb NANOG I gave a lightning talk on trends involving dual-stack
ASes, beginning with the fraction of AS-level paths that are the same in
IPv4 and IPv6. As of Jan 2012, 40-50% of AS-level paths are the same in
v4 and v6 for dual-stacked origin ASes.
http://www.nanog.org/meetings/nanog54/presentations/Monday/Luckie_LT.pdf
We've looked further into the evolution of IPv6 since then. In
particular we looked at "what could be". We find that 95% of AS-level
paths could be the same today: where an IPv4 path contains ASes that are
not found in an IPv6 path to the same dual-stacked origin, we check to
see if the AS is observed in an IPv6 BGP path, and thus the AS is IPv6
capable at a minimum. A brief blog post on this is at:
http://blog.caida.org/best_available_data/2012/06/04/ipv6-what-could-be-but-isnt-yet/
Matthew
From owen at delong.com Mon Jun 4 17:59:33 2012
From: owen at delong.com (Owen DeLong)
Date: Mon, 4 Jun 2012 15:59:33 -0700
Subject: IPv6 day and tunnels
In-Reply-To: <4FCD37F7.2050201@ttec.com>
References: <4FCC11B2.2090405@ttec.com>
<4FCC4A6F.30907@necom830.hpcl.titech.ac.jp>
<25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org>
<4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp>
<530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org>
<07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net>
<4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com>
<4FCD37F7.2050201@ttec.com>
Message-ID:
On Jun 4, 2012, at 3:34 PM, Joe Maimon wrote:
>
>
> Owen DeLong wrote:
>
>>
>>> Fail.
>>>
>>
>> What, exactly are you saying is a failure? The single word here even in context is
>> very ambiguous.
>
> The failure is that even now, when tunnels are critical to transition, a proper solution that improves on the IPv4 problems does not exist
>
A proper solution does exist... Stop blocking PTB messages. That's the proper solution. It was the proper solution in IPv4 and it is the proper solution in IPv6.
> And if tunnels do become less prevalent there will be even less impetus than now to make things work better.
True, perhaps, but, I don't buy that tunnels are the only sub-1500 octet MTU out there, so, I think your premise here is somewhat flawed.
>
>
>>
>>> Today, most people cant even get IPv6 without tunnels.
>>
>> Anyone can get IPv6 without a tunnel if they are willing to bring a circuit to the right place.
>
> Today most people cant even get IPv6 without tunnels, or without paying excessively more for their internet connection, or without having their pool of vendors shrink dramatically, sometimes to the point of none.
It never shrinks to none, but, yes, the cost can go up dramatically. You can, generally, get a circuit to somewhere that HE has presence from almost anywhere in the world if you are willing to pay for it. Any excessive costs would be what the circuit vendor charges. HE sells transit pretty cheap and everywhere we sell, it's dual-stack native. Sure, we wish we could magically have POPs everywhere and serve every customer with a short local loop. Unfortunately, that's not economically viable at this time, so, we build out where we can when there is sufficient demand to cover our costs. Pretty much like any other provider, I would imagine. Difference is, we've been building everything native dual stack for years. IPv6 is what we do. We're also pretty good at IPv4, so we deliver legacy connectivity to those that want it as well.
>>
>> Breaking PMTU-D is bad. People should stop doing so.
>>
>> Blocking PTB messages is bad in IPv4 and worse in IPv6.
>
> It has always been bad and people have not stopped doing it. And intentional blocking is not the sole cause of pmtud breaking.
>
I guess that depends on how you define the term intentional. I don't care whether it was the administrators intent, or a default intentionally placed there by the firewall vendor or what, it was someone's intent, therefore, yes, it is intentional. If you can cite an actual case of accidental dropping of PTB messages that was not the result of SOMEONE's intent, then, OK. However, at least on IPv6, I believe that intentional blocking (regardless of whose intent) is, in fact, the only source of PMTUD breakage at this point. In IPv4, there is some breakage in older software that didn't do PMTUD right even if it received the correct packets, but, that's not relevant to IPv6.
>>
>> If you have a useful alternative solution to propose, put it forth and let's discuss the merits.
>
> PMTU-d probing, as recently standardizes seems a more likely solution. Having CPE capable of TCP mss adjustment on v6 is another one. Being able to fragment when you want to is another good one as well.
>
Fragments are horrible from a security perspective and worse from a network processing perspective. Having a way to signal path MTU is much better. Probing is fine, but, it's not a complete solution and doesn't completely compensate for the lack of PTB message transparency.
>> I hope not. I hope that IPv6 will cause people to actually re-evaluate their behavior WRT PMTU-D and correct the actual problem. Working PMTU-D allows not only 1500, but also 1280, and 9000 and>9000 octet datagrams to be possible and segments that support<1500 work almost as well as segments that support jumbo frames. Where jumbo frames offer an end-to-end advantage, that advantage can be realized. Where there is a segment with a 1280 MTU, that can also work with a relatively small performance penalty.
>>
>> Where PMTU-D is broken, nothing works unless the MTU end-to-end happens to coincide with the smallest MTU.
>>
>> For links that carry tunnels and clear traffic, life gets interesting if one of them is the one with the smallest MTU regardless of the MTU value chosen.
>>
>> Owen
>>
>
> I dont share your optimism that it will go any better this time around than last. If it goes at all.
>
It is clearly going, so, the if it goes at all question is already answered. We're already seeing a huge ramp in IPv6 traffic leading up to ISOC's big celebration of my birthday (aka World IPv6 Launch) since early last week. I have no reason to expect that that traffic won't remain at the new higher levels after June 6. There are too many ISPs, Mobile operators, Web site operators and others committed at this point for it not to actually go. Also, since there's no viable alternative if it doesn't go, that pretty well insures that it will go one way or another.
As to my optimism, please don't mistake my statement of hope for any form of expectation. I _KNOW_ how bad it is. I live behind tunnels for IPv4 and IPv6 and have these issues on a regular basis.
Usually I'm able to work around them. Sometimes I'm even able to get people to actually fix their firewalls.
The good news is...
+ If we can get people to stop deploying bad filters
+ And we keep fixing the existing bad filters
Eventually, bad filters disappear.
Yes, that's two big ifs, but, it's worth a try.
Owen
> Joe
From Fred.L.Templin at boeing.com Mon Jun 4 18:13:06 2012
From: Fred.L.Templin at boeing.com (Templin, Fred L)
Date: Mon, 4 Jun 2012 16:13:06 -0700
Subject: IPv6 day and tunnels
In-Reply-To:
References: <4FCC11B2.2090405@ttec.com>
<4FCC4A6F.30907@necom830.hpcl.titech.ac.jp>
<25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org>
<4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp>
<530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org>
<07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net>
<4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com>
<4FCD37F7.2050201@ttec.com>
Message-ID:
Hi Owen,
I am 100% with you on wanting to see an end to filtering
of ICMPv6 PTBs. But, tunnels can take matters into their
own hands today to make sure that 1500 and smaller gets
through no matter if PTBs are delivered or not. There
doesn't really even need to be a spec as long as each
tunnel takes the necessary precautions to avoid messing
up the final destination.
The next thing is to convince the hosts to implement
RFC4821...
Thanks - Fred
fred.l.templin at boeing.com
> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: Monday, June 04, 2012 4:00 PM
> To: Joe Maimon
> Cc: nanog at nanog.org
> Subject: Re: IPv6 day and tunnels
>
>
> On Jun 4, 2012, at 3:34 PM, Joe Maimon wrote:
>
> >
> >
> > Owen DeLong wrote:
> >
> >>
> >>> Fail.
> >>>
> >>
> >> What, exactly are you saying is a failure? The single word here even in
> context is
> >> very ambiguous.
> >
> > The failure is that even now, when tunnels are critical to transition, a
> proper solution that improves on the IPv4 problems does not exist
> >
>
> A proper solution does exist... Stop blocking PTB messages. That's the
> proper solution. It was the proper solution in IPv4 and it is the proper
> solution in IPv6.
>
> > And if tunnels do become less prevalent there will be even less impetus
> than now to make things work better.
>
> True, perhaps, but, I don't buy that tunnels are the only sub-1500 octet
> MTU out there, so, I think your premise here is somewhat flawed.
>
> >
> >
> >>
> >>> Today, most people cant even get IPv6 without tunnels.
> >>
> >> Anyone can get IPv6 without a tunnel if they are willing to bring a
> circuit to the right place.
> >
> > Today most people cant even get IPv6 without tunnels, or without paying
> excessively more for their internet connection, or without having their
> pool of vendors shrink dramatically, sometimes to the point of none.
>
> It never shrinks to none, but, yes, the cost can go up dramatically. You
> can, generally, get a circuit to somewhere that HE has presence from
> almost anywhere in the world if you are willing to pay for it. Any
> excessive costs would be what the circuit vendor charges. HE sells transit
> pretty cheap and everywhere we sell, it's dual-stack native. Sure, we wish
> we could magically have POPs everywhere and serve every customer with a
> short local loop. Unfortunately, that's not economically viable at this
> time, so, we build out where we can when there is sufficient demand to
> cover our costs. Pretty much like any other provider, I would imagine.
> Difference is, we've been building everything native dual stack for years.
> IPv6 is what we do. We're also pretty good at IPv4, so we deliver legacy
> connectivity to those that want it as well.
>
> >>
> >> Breaking PMTU-D is bad. People should stop doing so.
> >>
> >> Blocking PTB messages is bad in IPv4 and worse in IPv6.
> >
> > It has always been bad and people have not stopped doing it. And
> intentional blocking is not the sole cause of pmtud breaking.
> >
>
> I guess that depends on how you define the term intentional. I don't care
> whether it was the administrators intent, or a default intentionally
> placed there by the firewall vendor or what, it was someone's intent,
> therefore, yes, it is intentional. If you can cite an actual case of
> accidental dropping of PTB messages that was not the result of SOMEONE's
> intent, then, OK. However, at least on IPv6, I believe that intentional
> blocking (regardless of whose intent) is, in fact, the only source of
> PMTUD breakage at this point. In IPv4, there is some breakage in older
> software that didn't do PMTUD right even if it received the correct
> packets, but, that's not relevant to IPv6.
>
> >>
> >> If you have a useful alternative solution to propose, put it forth and
> let's discuss the merits.
> >
> > PMTU-d probing, as recently standardizes seems a more likely solution.
> Having CPE capable of TCP mss adjustment on v6 is another one. Being able
> to fragment when you want to is another good one as well.
> >
>
> Fragments are horrible from a security perspective and worse from a
> network processing perspective. Having a way to signal path MTU is much
> better. Probing is fine, but, it's not a complete solution and doesn't
> completely compensate for the lack of PTB message transparency.
>
> >> I hope not. I hope that IPv6 will cause people to actually re-evaluate
> their behavior WRT PMTU-D and correct the actual problem. Working PMTU-D
> allows not only 1500, but also 1280, and 9000 and>9000 octet datagrams to
> be possible and segments that support<1500 work almost as well as segments
> that support jumbo frames. Where jumbo frames offer an end-to-end
> advantage, that advantage can be realized. Where there is a segment with a
> 1280 MTU, that can also work with a relatively small performance penalty.
> >>
> >> Where PMTU-D is broken, nothing works unless the MTU end-to-end happens
> to coincide with the smallest MTU.
> >>
> >> For links that carry tunnels and clear traffic, life gets interesting
> if one of them is the one with the smallest MTU regardless of the MTU
> value chosen.
> >>
> >> Owen
> >>
> >
> > I dont share your optimism that it will go any better this time around
> than last. If it goes at all.
> >
>
> It is clearly going, so, the if it goes at all question is already
> answered. We're already seeing a huge ramp in IPv6 traffic leading up to
> ISOC's big celebration of my birthday (aka World IPv6 Launch) since early
> last week. I have no reason to expect that that traffic won't remain at
> the new higher levels after June 6. There are too many ISPs, Mobile
> operators, Web site operators and others committed at this point for it
> not to actually go. Also, since there's no viable alternative if it
> doesn't go, that pretty well insures that it will go one way or another.
>
> As to my optimism, please don't mistake my statement of hope for any form
> of expectation. I _KNOW_ how bad it is. I live behind tunnels for IPv4 and
> IPv6 and have these issues on a regular basis.
>
> Usually I'm able to work around them. Sometimes I'm even able to get
> people to actually fix their firewalls.
>
> The good news is...
>
> + If we can get people to stop deploying bad filters
> + And we keep fixing the existing bad filters
>
> Eventually, bad filters disappear.
>
> Yes, that's two big ifs, but, it's worth a try.
>
> Owen
>
> > Joe
From mohta at necom830.hpcl.titech.ac.jp Mon Jun 4 18:40:01 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Tue, 05 Jun 2012 08:40:01 +0900
Subject: IPv6 day and tunnels
In-Reply-To: