Re: Programmers with network engineering skills

[Jeroen van Aart]

Joe Greco wrote:

The ideal world contains a mix of techniques.


Yes and copying parts of relevant code of an MTA could be one.


You cannot just blindly leave it to the MTA to decide what's valid.
Along that path lies madness.  How do you pass the address to the MTA?
Don't do it as a system() call unless you want someone to own your
box with a semicolon. 


Well, the whole world can pass whatever it wants to an MTA, it's 
supposed to be listening on internet facing port 25 all the time, that's 
it's mean reason of existence. An MTA is particularly well suited to 
take any kind of abuse, because that's exactly what it's expecting.


Unless in cases such as Owen mentioned I'd say it's a pretty good 
solution. The madness to me lies in making your own email validating code...


Greetings,
Jeroen

--
Earthquake Magnitude: 4.5
Date: Tuesday, March 13, 2012 04:15:05 UTC
Location: Dominican Republic region
Latitude: 19.3644; Longitude: -68.0645
Depth: 19.20 km

Re: Shim6, was: Re: filtering /48 is going to be necessary

[William Herrin]

On Mon, Mar 12, 2012 at 10:42 PM, Josh Hoppes  wrote:
> On Mon, Mar 12, 2012 at 8:01 PM, William Herrin  wrote:
>> Which would be just dandy for mobile IP applications.
>
> DNS handles many of millions of records sure, but that's because it
> was designed with caching in mind. DNS changes are rarely done at the
> rapid I think you are suggesting except for those who can stand the
> brunt of 5 minute time to live values. I think it would be insane to
> try and set a TTL much lower then that, but that would seem to work
> counter to the idea of sub 10 second loss. If you cut down caching as
> significantly as I think this idea would suggest I would expect
> scaling will take a plunge.

Hi Josh,

Actually, there was a study presented a few years ago. I think it was
at a Fall NANOG. At any rate, a gentleman at a university decided to
study the impact of adjusting the DNS TTL on the query count hitting
his authoritative server. IIRC he tested ranges from 24 hours to 60
seconds. In my opinion he didn't control properly for browser DNS
pinning (which would tend to suppress query count) but even with that
taken into account, the increase in queries due to decreased TTLs was
much less than you might expect.


> Also consider the significant increased load on DNS servers to
> handling the constant stream of dynamic DNS updates to make this
> possible, and that you have to find some reliable trust mechanism to
> handle these updates because with out that you just made man in the
> middle attacks a just a little bit easier.

That's absolutely correct. We would see a ten-factor increase in load
on the naming system and could see as much as a two order of magnitude
increase in load. But not on the root -- that load increase is
distributed almost exclusively to the leaves. And DNS has long since
proven it can scale up many orders of magnitude more than that. By
adding servers to be sure... but the DNS job parallelizes trivially
and well. Route processing, like with BGP, doesn't.

And you're right about implementing a trust mechanism suitable for
such an architecture. There's quite a bit of cryptographic work
already present in DNS updates but I frankly have no idea whether it
would hold up here or whether something new would be required. If it
can be reduced to "hostname and DNS password," and frankly I'd be
shocked if it couldn't, then any problem should be readily solvable.


> That said, I might be misunderstanding something. I would like to see
> that idea elaborated.

>From your questions, it sounds like you're basically following the concept.

I sketched out the idea a couple years ago, working through some of
the permutations. And the MPTCP working group has been chasing some of
the concepts for a while too, though last I checked they'd fallen into
one of the major architectural pitfalls of shim6, trying to bootstrap
the address list instead of relying on a mapper.

The main problem is that we "can't get there from here." No set of
changes modest enough to not be another "IPv6 transition" gets the job
done.

We'd need to entrench smaller steps in the direction of such a
protocol first. Like enhancing the sockets API with a variant of
connect() which expects to take a host name and service name and
return a connected protocol-agnostic socket. Today, just some
under-the-hood calls to a non-blocking getaddrinfo and some
parallelized connect()'s that happens to work better and be an easier
choice than what most folks could write for themselves. But in the
future, a socket connection call which receives all the knowledge that
a multi-addressed protocol needs to get the job done without further
changes to the application's code.

Or, if I'm being fair about it, doing what the MPTCP folks are doing
and then following up later with additional enhancements to call out
to DNS from the TCP layer.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Shim6, was: Re: filtering /48 is going to be necessary

[William Herrin]

On Mon, Mar 12, 2012 at 11:33 PM, Geoff Huston  wrote:
> On 13/03/2012, at 8:14 AM, Iljitsch van Beijnum wrote:
>> On 12 Mar 2012, at 21:15 , William Herrin wrote:
>>> Not at all. You just build a second tier to the routing system.
>>
>> It's so strange how people think a locator/identifier split
>> will solve the scalability problem. We already have two
>> tiers: DNS names and IP addresses. So that didn't solve
>> anything. I don't see any reason a second second tier would.
>
> I think you have encountered an article of faith Iljitsch :-)
>
>    http://en.wikipedia.org/wiki/Indirection:  Any problem can be solved by 
> adding another layer of indirection.

"But that usually will create another problem."

Then the test must be: does any particular proposed layer of
indirection solve more intractable and more valuable problems than it
creates, enough more valuable to be worth the cost of implementation?

Still, I concede that it would be "better" to more effectively use the
indirection layer we have (DNS) rather than create another. Better,
but not necessarily achievable.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Geoff Huston]

On 13/03/2012, at 8:14 AM, Iljitsch van Beijnum wrote:

> On 12 Mar 2012, at 21:15 , William Herrin wrote:
> 
>> Not at all. You just build a second tier to the routing system.
> 
> It's so strange how people think a locator/identifier split will solve the 
> scalability problem. We already have two tiers: DNS names and IP addresses. 
> So that didn't solve anything. I don't see any reason a second second tier 
> would.

I think you have encountered an article of faith Iljitsch :-)

http://en.wikipedia.org/wiki/Indirectio:  Any problem can be solved by 
adding another layer of indirection.

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Geoff Huston]

On 13/03/2012, at 2:31 AM, Leo Bicknell wrote:

> In a message written on Mon, Mar 12, 2012 at 11:07:54AM -0400, Robert E. 
> Seastrom wrote:
>> Grass-roots, bottom-up policy process
>> +
>> Need for multihoming
>> +
>> Got tired of waiting
>> =
>> IPv6 PI
> 
> I'll also add that Shim6 folks never made a good economic argument.
> It's true that having routes in the DFZ costs money, and that
> reducing the number of routes will save the industry money in router
> upgrades and such to handle more routes.  However, it's also true
> that deploying SHIM6 (or similar solutions) also has a cost in
> rewritten software, traning for network engineers and administrators,
> and so on.
> 
> It was never clear to me that even if it worked 100% as advertised that
> it would be cheaper / better in the global sense.
> 

I think that's asking too much of the IETF Leo - Shim6 went through much the
same process as most of the IETF work these days: bubble of thought, BOF sanity
check, requirements work, protocol prototyping, technology specification.

Yes, the economics of routing are strange, and the lack of any real strictures
in the routing tables are testament to the observation that despite more than
two decades of tossing the idea around we've yet to find the equivalent of a 
"route deaggregation tax" or a "route advertisement tax"  or any other mechanism
that effectively turns the routing space into a form of market that imposes
some economic constraints on the activity. So after so long looking for such
a framework in routing, the hope that someday we will figure it out
gets smaller and smaller every day.

And in some ways the routing explosion problem is one of fear rather than 
actuality - the growth rates of the IPv4 routing table have been sitting at
around 8% - 15% p.a. for many years. oWhile you can't route the Internet on 
15 year old hardware, the growth figures are still low enough under Moore's 
Law that the unit cost of routing is not escalating at levels that are
notably higher than other cost elements for an ISP. Its not the routing
table explosion that will cause you to raise your fees or worse, go 
bankrupt tomorrow.

So in some ways for Shim6 to have a "good economic argument" I suspect
that Shim6 would have to have pulled out of thin air an approach that
completely externalised the cost of routing, and made routing completely
free for ISPs. And that is simply fantasy land!

Geoff


 

Re: Programmers with network engineering skills

[Mark Andrews]

In message <201203130131.q2d1vlxa087...@aurora.sol.net>, Joe Greco writes:
> > Owen DeLong wrote:
> > > http://en.wikipedia.org/wiki/Email_address#Valid_email_addresses
> > > 
> > > You may have noticed my particular test wouldn't accept foo!bar!ucbvax!us
> er format addresses, either.
> > > 
> > > It works well enough for my purposes. I did not claim it was perfect.
> > 
> > Why not leave it to the MTA to decide what is a valid address? It only 
> > requires a few SMTP commands to the MTA to know if it will accept it. 
> > Normally the MTA will tell you after the "rcpt to:" command if it will 
> > accept it (i'm ignoring some badly behaving MTAs who will swallow 
> > anything and then bounce, no point trying to work around such crap).
> > 
> > No need to re-invent the wheel, unless you're actually creating an MTA 
> > or something similar.
> > 
> > Who is to say that even IF your address verifier verifies it as valid 
> > that the MTA is configured to allow it (or the other way around)? MTAs 
> > can be arbitrarily configured to (dis)allow "bang path" addresses, IP 
> > addresses etc.
> 
> The ideal world contains a mix of techniques.
> 
> You cannot just blindly leave it to the MTA to decide what's valid.
> Along that path lies madness.  How do you pass the address to the MTA?
> Don't do it as a system() call unless you want someone to own your
> box with a semicolon.

Only if you don't properly quote/escape the arguments you are passing.

>  Do you allow \n?  \r?  Do you allow \\?  There
> is a certain amount of paranoia that is prudent, and a certain amount
> that is actually necessary...  though it's true that implementations
> often don't bother to work that out correctly...
> 
> ... JG
> -- 
> Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
> "We call it the 'one bite at the apple' rule. Give me one chance [and] then I
> won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CN
> N)
> With 24 million small businesses in the US alone, that's way too many apples.
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Mark Andrews]

In message 
, Josh Hoppes writes:
> Also consider the significant increased load on DNS servers to
> handling the constant stream of dynamic DNS updates to make this
> possible, and that you have to find some reliable trust mechanism to
> handle these updates because with out that you just made man in the
> middle attacks a just a little bit easier.

The DNS already supports cryptographically authenticated updates.
There is a good chance that your DHCP server used one of the methods
below when you got your lease.

SIG(0), TSIG and GSS_TSIG all scale appropiately for this.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Programmers with network engineering skills

[Keegan Holley]

On Mar 12, 2012, at 5:32 PM, Owen DeLong  wrote:

> 
> On Mar 12, 2012, at 2:12 PM, Keegan Holley wrote:
> 
>> 2012/3/12 Tei 
>> 
>>> On 12 March 2012 09:59, Carlos Martinez-Cagnazzo 
>>> wrote:
 Hey!
 
 On 3/8/12 8:24 PM, Lamar Owen wrote:
> On Monday, March 05, 2012 09:36:41 PM Jimmy Hess wrote:
> ...
>>  (16)  The default gateway's IP address is always 192.168.0.1
>>  (17) The user portion of E-mail addresses never contain special
>> characters like  "-" "+"  "$"   "~"  "."  ",", "[",  "]"
 I've just had my ' xx AT cagnazzo.name' email address rejected by a web
 form saying that 'it is not a valid email address'. So I guess point
 (17) can be extended to say that 'no email address shall end in anything
 different that .com, .net or the local ccTLD'
 
 :=)
 
 Carlos
>>> 
>>> 
>>> Yea, I don't even know how programmers can get that wrong.  The regex
>>> is not even hard or anything.
>>> 
>>> 
>>> 
>>> (?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])
>>> 
>>> 
>> I bet it's even harder without the use of a search engine.
> 
> Whenever I've built code to check someone's email address on a form, I always 
> just looked for the following:
> 
> 1.matches ^[^@]+@[A-Za-z0-0\-\.]+[A-Za-z]$
> 2.The component to the right of the @ sign returns at least one A, , 
> or MX record.
> 
> If it passed those two checks, I figured that was about as good as I could do 
> without resorting to one of the following:
>1.An incomprehensible and unmaintainable regex as the one above
>2.Actually attempting delivery to said address
> 
> Owen
> 

I've done some scripting with the similar goals and to be completely honest 
I've skews at least consulted google.  It's much easier to read and test a 
regular expression like the one above than to write one from scratch.  
Sometimes it takes an incomprehensible regex to be thorough. Sometimes close 
enough really is close enough though. It depends on the problem you are trying 
to solve.   
> 

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Josh Hoppes]

On Mon, Mar 12, 2012 at 8:01 PM, William Herrin  wrote:
> But suppose you had a TCP protocol that wasn't statically bound to the
> IP address by the application layer. Suppose each side of the
> connection referenced each other by name, TCP expected to spread
> packets across multiple local and remote addresses, and suppose TCP,
> down at layer 4, expected to generate calls to the DNS any time it
> wasn't sure what addresses it should be talking to.
>
> DNS servers can withstand the update rate. And the prefix count is
> moot. DNS is a distributed database. It *already* easily withstands
> hundreds of millions of entries in the in-addr.arpa zone alone. And if
> the node gets even moderately good at predicting when it will lose
> availability for each network it connects to and/or when to ask the
> DNS again instead of continuing to try the known IP addresses you can
> get to where network drops are ordinarily lossless and only
> occasionally result in a few packet losses over the course of a a
> single-digit number of seconds.
>
> Which would be just dandy for mobile IP applications.

DNS handles many of millions of records sure, but that's because it
was designed with caching in mind. DNS changes are rarely done at the
rapid I think you are suggesting except for those who can stand the
brunt of 5 minute time to live values. I think it would be insane to
try and set a TTL much lower then that, but that would seem to work
counter to the idea of sub 10 second loss. If you cut down caching as
significantly as I think this idea would suggest I would expect
scaling will take a plunge.

Also consider the significant increased load on DNS servers to
handling the constant stream of dynamic DNS updates to make this
possible, and that you have to find some reliable trust mechanism to
handle these updates because with out that you just made man in the
middle attacks a just a little bit easier.

That said, I might be misunderstanding something. I would like to see
that idea elaborated.

Re: Whitelist of update servers

[Jeff Kell]

An "IP-based" whitelist is pretty much doomed  from the start.  Many
vendors use content delivery networks and that is too large and volatile
to chase.

We have had some success in captive portal environments with DNS
manipulation, allowing only certain domains to resolve, and redirecting
everything else to the portal.  The list is still non-trivial, but
manageable.

So don't manage it at the router level, you will have better luck at the
DNS layer.

Jeff

On 3/12/2012 8:51 PM, Randy Bush wrote:
> i tend to two defenses
>
>   o if it is not an urgent update, i wait to hear from peers that
> it is safe.
>
>   o i generally do not accept pop-up updates.  if one looks tasty,
> when possible i navigate directly to the site (yes, i know about
> dns spoofing) and download.

Re: Programmers with network engineering skills

[Joe Greco]

> Owen DeLong wrote:
> > http://en.wikipedia.org/wiki/Email_address#Valid_email_addresses
> > 
> > You may have noticed my particular test wouldn't accept foo!bar!ucbvax!user 
> > format addresses, either.
> > 
> > It works well enough for my purposes. I did not claim it was perfect.
> 
> Why not leave it to the MTA to decide what is a valid address? It only 
> requires a few SMTP commands to the MTA to know if it will accept it. 
> Normally the MTA will tell you after the "rcpt to:" command if it will 
> accept it (i'm ignoring some badly behaving MTAs who will swallow 
> anything and then bounce, no point trying to work around such crap).
> 
> No need to re-invent the wheel, unless you're actually creating an MTA 
> or something similar.
> 
> Who is to say that even IF your address verifier verifies it as valid 
> that the MTA is configured to allow it (or the other way around)? MTAs 
> can be arbitrarily configured to (dis)allow "bang path" addresses, IP 
> addresses etc.

The ideal world contains a mix of techniques.

You cannot just blindly leave it to the MTA to decide what's valid.
Along that path lies madness.  How do you pass the address to the MTA?
Don't do it as a system() call unless you want someone to own your
box with a semicolon.  Do you allow \n?  \r?  Do you allow \\?  There
is a certain amount of paranoia that is prudent, and a certain amount
that is actually necessary...  though it's true that implementations
often don't bother to work that out correctly...

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: Shim6, was: Re: filtering /48 is going to be necessary

[William Herrin]

2012/3/12 Masataka Ohta :
> William Herrin wrote:
>
>> When I ran the numbers a few years ago, a route had a global cost
>> impact in the neighborhood of $8000/year. It's tough to make a case
>> that folks who need multihoming's reliability can't afford to put that
>> much into the system.
>
> The cost for bloated DFZ routing table is not so small and is
> paid by all the players, including those who use DFZ but do
> not multihome.

Hi,

http://bill.herrin.us/network/bgpcost.html

If you believe there's an error in my methodology, feel free to take
issue with it.


>> Often overlooked is that multihoming through multi-addressing could
>> solve IP mobility too.
>
> Not.
>
> What is often overlooked is the fact that they are orthogonal
> problems.

I respectfully disagree. Current mobility efforts have gone down a
blind alley of relays from a home server and handoffs from one network
to the next. And in all fairness, with TCP tightly bound to a
particular IP address pair there aren't a whole lot of other options.
Nevertheless, it's badly suboptimal. Latency and routing inefficiency
rapidly increases with distance from the home node among other major
problems.

However, there's another way to imagine the problem: Networks become
available. Networks cease to be available. No handoff. No home server.
Just add and drop. Announce a route into the global system to each
available network with priority set based on the node's best estimate
of the network's bandwidth, likely future availablilty, etc. Cancel
the announcement for any network that has left or is leaving range.
Modify the announcement priority as the node's estimate of the network
evolves.

This is quite impossible with today's BGP core. The update rate would
crush the core, as would the prefix count. And if those problems were
magically solved, BGP still isn't capable of propagating a change fast
enough to be useful for mobile applications.

But suppose you had a TCP protocol that wasn't statically bound to the
IP address by the application layer. Suppose each side of the
connection referenced each other by name, TCP expected to spread
packets across multiple local and remote addresses, and suppose TCP,
down at layer 4, expected to generate calls to the DNS any time it
wasn't sure what addresses it should be talking to.

DNS servers can withstand the update rate. And the prefix count is
moot. DNS is a distributed database. It *already* easily withstands
hundreds of millions of entries in the in-addr.arpa zone alone. And if
the node gets even moderately good at predicting when it will lose
availability for each network it connects to and/or when to ask the
DNS again instead of continuing to try the known IP addresses you can
get to where network drops are ordinarily lossless and only
occasionally result in a few packet losses over the course of a a
single-digit number of seconds.

Which would be just dandy for mobile IP applications.


> The only end to end way to handle multiple addresses is to let
> applications handle them explicitly.

For connection-oriented protocols, that's nonsense. Pick an
appropriate mapping function and you can handle multiple layer 3
addresses just fine at layer 4. Just like we successfully handle layer
2 addresses at layer 3.

For connectionless protocols, maybe. Certainly layer 7 knowledge is
needed to decide whether each path is operational. However, I'm not
convinced that can't be reliably accomplished with a hinting process
where the application tells layer 4 its best guess of which send()'s
succeeded or failed and lets layer 4 figure out the resulting gory
details of address selection.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Whitelist of update servers

[Randy Bush]

i tend to two defenses

  o if it is not an urgent update, i wait to hear from peers that
it is safe.

  o i generally do not accept pop-up updates.  if one looks tasty,
when possible i navigate directly to the site (yes, i know about
dns spoofing) and download.

randy

Re: Programmers with network engineering skills

[Owen DeLong]

Sometimes you don't want to have your application exposed to an unconstrained 
wait outside
of your control.

Sometimes your application may not have access/permissions/etc. to open 
sockets. (This is actually
a common security precaution in some CGI environments).

Owen

On Mar 12, 2012, at 4:22 PM, Jeroen van Aart wrote:

> Owen DeLong wrote:
>> http://en.wikipedia.org/wiki/Email_address#Valid_email_addresses
>> You may have noticed my particular test wouldn't accept foo!bar!ucbvax!user 
>> format addresses, either.
>> It works well enough for my purposes. I did not claim it was perfect.
> 
> Why not leave it to the MTA to decide what is a valid address? It only 
> requires a few SMTP commands to the MTA to know if it will accept it. 
> Normally the MTA will tell you after the "rcpt to:" command if it will accept 
> it (i'm ignoring some badly behaving MTAs who will swallow anything and then 
> bounce, no point trying to work around such crap).
> 
> No need to re-invent the wheel, unless you're actually creating an MTA or 
> something similar.
> 
> Who is to say that even IF your address verifier verifies it as valid that 
> the MTA is configured to allow it (or the other way around)? MTAs can be 
> arbitrarily configured to (dis)allow "bang path" addresses, IP addresses etc.
> 
> Regards,
> Jeroen
> 
> -- 
> Earthquake Magnitude: 5.0
> Date: Monday, March 12, 2012 17:55:10 UTC
> Location: Kepulauan Talaud, Indonesia
> Latitude: 3.0222; Longitude: 127.0054
> Depth: 35.00 km

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Masataka Ohta]

William Herrin wrote:

> When I ran the numbers a few years ago, a route had a global cost
> impact in the neighborhood of $8000/year. It's tough to make a case
> that folks who need multihoming's reliability can't afford to put that
> much into the system.

The cost for bloated DFZ routing table is not so small and is
paid by all the players, including those who use DFZ but do
not multihome.

Those who can't pay the cost silently give up to be multihomed,
which is why you overlooked them.

Even those who pays the cost are not using full routing
table for IGP, which makes their multihoming less capable.

> A *working* multi-addressed end user system (like shim6 attempted)

Shim6 is too poorly designed that it does not work.

> Often overlooked is that multihoming through multi-addressing could
> solve IP mobility too.

Not.

What is often overlooked is the fact that they are orthogonal
problems.

> Carry
> your voip call uninterrupted from your home wifi on the cable modem to
> your cell provider in the car to your employer's wired ethernet and
> back.

Use mobile IP implemented long before shim6 was designed.

> Unfortunately, shim6 didn't work in some of the boundary cases. Since
> single-homing works pretty well in the ordinary case, there's not much
> point to a multihoming protocol that fails to deliver all the boundary
> cases.

Just like NAT, shim6 is an intelligent intermediate entity trying
to hide its existence from applications, which is why it does not
work sometimes just as NAT does not work sometimes.

The only end to end way to handle multiple addresses is to let
applications handle them explicitly.

Masataka Ohta

Re: Programmers with network engineering skills

[Jeroen van Aart]

Owen DeLong wrote:

http://en.wikipedia.org/wiki/Email_address#Valid_email_addresses

You may have noticed my particular test wouldn't accept foo!bar!ucbvax!user 
format addresses, either.

It works well enough for my purposes. I did not claim it was perfect.


Why not leave it to the MTA to decide what is a valid address? It only 
requires a few SMTP commands to the MTA to know if it will accept it. 
Normally the MTA will tell you after the "rcpt to:" command if it will 
accept it (i'm ignoring some badly behaving MTAs who will swallow 
anything and then bounce, no point trying to work around such crap).


No need to re-invent the wheel, unless you're actually creating an MTA 
or something similar.


Who is to say that even IF your address verifier verifies it as valid 
that the MTA is configured to allow it (or the other way around)? MTAs 
can be arbitrarily configured to (dis)allow "bang path" addresses, IP 
addresses etc.


Regards,
Jeroen

--
Earthquake Magnitude: 5.0
Date: Monday, March 12, 2012 17:55:10 UTC
Location: Kepulauan Talaud, Indonesia
Latitude: 3.0222; Longitude: 127.0054
Depth: 35.00 km

Re: Shim6, was: Re: filtering /48 is going to be necessary

[William Herrin]

On Mon, Mar 12, 2012 at 5:14 PM, Iljitsch van Beijnum
 wrote:
> On 12 Mar 2012, at 21:15 , William Herrin wrote:
>> Not at all. You just build a second tier to the routing system.
>
> We already have two tiers: DNS names and IP addresses.

Hi Iljitsch,

If only that were true. The DNS doesn't sit to the side of TCP,
managing the moment to moment layer 4 to layer 3 mapping function the
way ARP sits to the side of IP. Instead, the DNS's function is
actuated all the way up at layer 7.

This was the crux of my complaint about the getaddrinfo/connect APIs
last week. Their design makes a future introduction of a transport
protocol, something which actually does interact with the name service
at the proper layer, needlessly hard.

That and the common non-operation of the DNS TTL invalidates DNS' use
as a routing tier.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Programmers with network engineering skills

[Owen DeLong]

I think this proves one thing...

Given enough monkeys with typewriters, you will, in fact, not
get Shakespeare, but, instead, regular expressions for Shakespeare's
email address.

Owen

On Mar 12, 2012, at 3:09 PM, Paul Graydon wrote:

> On 03/12/2012 09:46 AM, Tei wrote:
>> On 12 March 2012 09:59, Carlos Martinez-Cagnazzo  
>> wrote:
>>> Hey!
>>> 
>>> On 3/8/12 8:24 PM, Lamar Owen wrote:
 On Monday, March 05, 2012 09:36:41 PM Jimmy Hess wrote:
 ...
>(16)  The default gateway's IP address is always 192.168.0.1
>(17) The user portion of E-mail addresses never contain special
> characters like  "-" "+"  "$"   "~"  "."  ",", "[",  "]"
>>> I've just had my ' xx AT cagnazzo.name' email address rejected by a web
>>> form saying that 'it is not a valid email address'. So I guess point
>>> (17) can be extended to say that 'no email address shall end in anything
>>> different that .com, .net or the local ccTLD'
>>> 
>>> :=)
>>> 
>>> Carlos
>> 
>> Yea, I don't even know how programmers can get that wrong.  The regex
>> is not even hard or anything.
>> 
>> 
>> (?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])
>> 
>> 
> It's supposedly a lot harder than that.  Try this for strict RFC822 
> compliance (from http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html):
> 
> (?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
> )+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
> \r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(
> ?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[
> \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0
> 31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
> ](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
> (?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
> (?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
> |(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
> ?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
> r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
> \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
> ?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t]
> )*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
> \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
> )(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
> )+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)
> *:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+
> |\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
> \n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:
> \r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
> ]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031
> ]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
> ?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?
> :(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
> :\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?
> :(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
> [ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\]
> \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
> \\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
> @,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
> (?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
> )*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
> ".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
> :[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[
> \]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-
> \031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(
> ?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
> :\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
> ^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
> .

Re: Programmers with network engineering skills

[Owen DeLong]

I don't believe that is true.

From RFC-821, it is true that:

@ONE, @TWO:JOE@THREE

Is supposed to be valid as a forward path, but, not an address. However,  I 
believe its
use is effectively, if not actually deprecated at this point.

It doesn't really describe address, per se, but, it does define mailbox as 
follows:

   mailbox

  A character string (address) which identifies a user to whom mail
  is to be sent.  Mailbox normally consists of the host and user
  specifications.  The standard mailbox naming convention is defined
  to be "user@domain".  Additionally, the "container" in which mail
  is stored.

Looking at more recent RFC 5321,

One important change is this:

   Only resolvable, fully-qualified domain names (FQDNs) are permitted
   when domain names are used in SMTP.  In other words, names that can
   be resolved to MX RRs or address (i.e., A or ) RRs (as discussed
   in Section 5) are permitted, as are CNAME RRs whose targets can be
   resolved, in turn, to MX or address RRs.  Local nicknames or
   unqualified names MUST NOT be used.  There are two exceptions to the
   rule requiring FQDNs:

   o  The domain name given in the EHLO command MUST be either a primary
  host name (a domain name that resolves to an address RR) or, if
  the host has no name, an address literal, as described in
  Section 4.1.3 and discussed further in the EHLO discussion of
  Section 4.1.4.

Regarding addresses, it says this:

2.3.11.  Mailbox and Address

   As used in this specification, an "address" is a character string
   that identifies a user to whom mail will be sent or a location into
   which mail will be deposited.  The term "mailbox" refers to that
   depository.  The two terms are typically used interchangeably unless
   the distinction between the location in which mail is placed (the
   mailbox) and a reference to it (the address) is important.  An
   address normally consists of user and domain specifications.  The
   standard mailbox naming convention is defined to be
   "local-part@domain"; contemporary usage permits a much broader set of
   applications than simple "user names".  Consequently, and due to a
   long history of problems when intermediate hosts have attempted to



Klensin Standards Track[Page 15]
 
RFC 5321  SMTP  October 2008


   optimize transport by modifying them, the local-part MUST be
   interpreted and assigned semantics only by the host specified in the
   domain part of the address.


Yes, there are user parts that are technically valid which my regex would 
reject. There are also some invalid addresses which I don't reject (for 
example, I won't reject a...@example.com).

If you want to get truly pathologically pedantic  about it:

http://en.wikipedia.org/wiki/Email_address#Valid_email_addresses

You may have noticed my particular test wouldn't accept foo!bar!ucbvax!user 
format addresses, either.

It works well enough for my purposes. I did not claim it was perfect.

Owen

On Mar 12, 2012, at 3:01 PM, William Herrin wrote:

> On Mon, Mar 12, 2012 at 5:32 PM, Owen DeLong  wrote:
>> Whenever I've built code to check someone's email address on a form, I 
>> always just looked for the following:
>> 
>> 1.  matches ^[^@]+@[A-Za-z0-0\-\.]+[A-Za-z]$
>> 2.  The component to the right of the @ sign returns at least one A, 
>> , or MX record.
> 
> Hi Owen,
> 
> If I'm not mistaken, "B@M4N"@delong.com is a legitimately formatted
> email address which fails part one of your test. Something along the
> lines of @delong.com;bob@some.private.network is also supposed to be
> legit though it's been so long since I looked at it that I may have
> munged the format.
> 
> No, I don't allow these in systems I've designed either. Just sayin'.
> 
> Regards,
> Bill Herrin
> 
> 
> 
> -- 
> William D. Herrin  her...@dirtside.com  b...@herrin.us
> 3005 Crane Dr. .. Web: 
> Falls Church, VA 22042-3004

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Łukasz Bromirski]

On 2012-03-12 22:14, Iljitsch van Beijnum wrote:

On 12 Mar 2012, at 21:15 , William Herrin wrote:


Not at all. You just build a second tier to the routing system.


It's so strange how people think a locator/identifier split will solve

> the scalability problem. We already have two tiers: DNS names and IP
> addresses. So that didn't solve anything. I don't see any reason a
> second second tier would.

Wrong analogy IMHO.

Using it, you'd know how to get to specific host in IPv4/IPv6-centric
Internet by looking up it's name. Knowing a host is 'thishost.org'
doesn't give you information needed to route IPv4/v6 packets that we
still use, to this specific system. You still need to lookup the IP
assigned to this name.

For LISP (other solutions may vary obviously) knowing node 54.100 is
available (after lookup) currently at 200.101 makes possibility for
core routers to only remember the paths to 200.101/16 and not
thousands of this prefix aggregates. This is aggregation of information
at the same level of lookup execution.

The real problems for world-wide LISP adoption are currently:
 - nobody sees a FIB explosion for IPv6, because
 - only around 8k worth of prefixes is in the global IPv6 table

Hardly a reason for anyone to implement aggregation. If IPv6 would
reach todays IPv4 level of 400k it would be still not a very compelling
reason apart from those SPs willing to run all their edge without MPLS
and with L3 devices that have very tiny FIBs - like 2/4/8k of entries.
Typical core router has ability to forward 2-3M of IPv4 prefixes in
hardware, and around 500k-2M of IPv6 prefixes in hardware - today.

Ideal LISP use case would be for example 4M of IPv6 prefixes with
steady clearly visible growth. Aggregating this down to for example
(I've made this completely up) 200k prefixes and still having
ability to traffic engineer the paths between the source and destination
almost at the levels of having all 4M prefixes in FIB is very compelling
reason to deploy LISP.

--
"There's no sense in being precise when |   Łukasz Bromirski
 you don't know what you're talking |  jid:lbromir...@jabber.org
 about."   John von Neumann |http://lukasz.bromirski.net

Re: Programmers with network engineering skills

[Paul Graydon]

On 03/12/2012 09:46 AM, Tei wrote:

On 12 March 2012 09:59, Carlos Martinez-Cagnazzo  wrote:

Hey!

On 3/8/12 8:24 PM, Lamar Owen wrote:

On Monday, March 05, 2012 09:36:41 PM Jimmy Hess wrote:
...

(16)  The default gateway's IP address is always 192.168.0.1
(17) The user portion of E-mail addresses never contain special
characters like  "-" "+"  "$"   "~"  "."  ",", "[",  "]"

I've just had my ' xx AT cagnazzo.name' email address rejected by a web
form saying that 'it is not a valid email address'. So I guess point
(17) can be extended to say that 'no email address shall end in anything
different that .com, .net or the local ccTLD'

:=)

Carlos


Yea, I don't even know how programmers can get that wrong.  The regex
is not even hard or anything.


(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])


It's supposedly a lot harder than that.  Try this for strict RFC822 
compliance (from http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html):


(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ 
\t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(
?:\r\n)?[ 
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] 
\000-\0
31]+(?:(?:(?:\r\n)?[ 
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] 
\000-\031]+
(?:(?:(?:\r\n)?[ 
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ 
\t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ 
\t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\
r\n)?[ 
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
 \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)
?[ 
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[

 \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ 
\t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ 
\t])+
|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ 
\t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?:(?:
\r\n)?[ 
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] 
\000-\031
]+(?:(?:(?:\r\n)?[ 
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?
:(?:(?:\r\n)?[ 
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] 
\000-\031]+(?:(?
:(?:\r\n)?[ 
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ 
\t])*(?:(?:(?:[^()<>@,;:\\".\[\]
\000-\031]+(?:(?:(?:\r\n)?[ 
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ 
\t])*(?:[^()<>
@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ 
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ 
\t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ 
\t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ 
\t])*(?
:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ 
\t])+|\Z|(?=[\["()<>@,;:\\".\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] 
\000-
\031]+(?:(?:(?:\r\n)?[ 
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ 
\t])*(?:@(?:[^()<>@,;
:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ 
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ 
\t])*(?:[^()<>@,;:\\"
.\[\] \000-\031]+(?:(?:(?:\r\n)?[ 
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\
]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ 
\t])*(?:[^()<>@,;:\\".\
[\] \000-\031]+(?:(?:(?:\r\n)?[ 
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ 
\t])*(?:[^()<>@,;:\\".\[\]
\000-\031]+(?:(?:(?:\r\n)?[ 
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]

Re: Programmers with network engineering skills

[William Herrin]

On Mon, Mar 12, 2012 at 5:32 PM, Owen DeLong  wrote:
> Whenever I've built code to check someone's email address on a form, I always 
> just looked for the following:
>
> 1.      matches ^[^@]+@[A-Za-z0-0\-\.]+[A-Za-z]$
> 2.      The component to the right of the @ sign returns at least one A, 
> , or MX record.

Hi Owen,

If I'm not mistaken, "B@M4N"@delong.com is a legitimately formatted
email address which fails part one of your test. Something along the
lines of @delong.com;bob@some.private.network is also supposed to be
legit though it's been so long since I looked at it that I may have
munged the format.

No, I don't allow these in systems I've designed either. Just sayin'.

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Programmers with network engineering skills

[Michael Thomas]

On 03/12/2012 02:32 PM, Owen DeLong wrote:
Whenever I've built code to check someone's email address on a form, I always just looked for the following: 1. matches ^[^@]+@[A-Za-z0-0\-\.]+[A-Za-z]$ 2. The component to the right of the @ sign returns at least one A, , or MX record. If it passed those two checks, I figured that was about as good as I could do without resorting to one of the following: 1. An incomprehensible and unmaintainable regex as the one above 2. Actually attempting delivery to said address Owen 


"'I know, I'll use a regular expression!' now you have two problems."

Mike

Re: Programmers with network engineering skills

[Owen DeLong]

On Mar 12, 2012, at 2:12 PM, Keegan Holley wrote:

> 2012/3/12 Tei 
> 
>> On 12 March 2012 09:59, Carlos Martinez-Cagnazzo 
>> wrote:
>>> Hey!
>>> 
>>> On 3/8/12 8:24 PM, Lamar Owen wrote:
 On Monday, March 05, 2012 09:36:41 PM Jimmy Hess wrote:
 ...
>   (16)  The default gateway's IP address is always 192.168.0.1
>   (17) The user portion of E-mail addresses never contain special
> characters like  "-" "+"  "$"   "~"  "."  ",", "[",  "]"
>>> I've just had my ' xx AT cagnazzo.name' email address rejected by a web
>>> form saying that 'it is not a valid email address'. So I guess point
>>> (17) can be extended to say that 'no email address shall end in anything
>>> different that .com, .net or the local ccTLD'
>>> 
>>> :=)
>>> 
>>> Carlos
>> 
>> 
>> Yea, I don't even know how programmers can get that wrong.  The regex
>> is not even hard or anything.
>> 
>> 
>> 
>> (?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])
>> 
>> 
> I bet it's even harder without the use of a search engine.

Whenever I've built code to check someone's email address on a form, I always 
just looked for the following:

1.  matches ^[^@]+@[A-Za-z0-0\-\.]+[A-Za-z]$
2.  The component to the right of the @ sign returns at least one A, , 
or MX record.

If it passed those two checks, I figured that was about as good as I could do 
without resorting to one of the following:
1.  An incomprehensible and unmaintainable regex as the one above
2.  Actually attempting delivery to said address

Owen

Re: US withdraws IANA RFP, ‘no suitable responses’

[Stefan Fouant]

Was waiting for a response from Eric and without fail he comes through in 
record time... :-b

Stefan Fouant
JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI
Technical Trainer, Juniper Networks

Follow us on Twitter @JuniperEducate

Sent from my iPad

On Mar 12, 2012, at 4:14 PM, Eric Brunner-Williams  wrote:

> good head line copy edit.
> 
> body lacks substance, though not attitude.
> 
> -e
> 

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Iljitsch van Beijnum]

On 12 Mar 2012, at 21:15 , William Herrin wrote:

> Not at all. You just build a second tier to the routing system.

It's so strange how people think a locator/identifier split will solve the 
scalability problem. We already have two tiers: DNS names and IP addresses. So 
that didn't solve anything. I don't see any reason a second second tier would.

Re: Programmers with network engineering skills

[Keegan Holley]

2012/3/12 Tei 

> On 12 March 2012 09:59, Carlos Martinez-Cagnazzo 
> wrote:
> > Hey!
> >
> > On 3/8/12 8:24 PM, Lamar Owen wrote:
> >> On Monday, March 05, 2012 09:36:41 PM Jimmy Hess wrote:
> >> ...
> >>>(16)  The default gateway's IP address is always 192.168.0.1
> >>>(17) The user portion of E-mail addresses never contain special
> >>> characters like  "-" "+"  "$"   "~"  "."  ",", "[",  "]"
> > I've just had my ' xx AT cagnazzo.name' email address rejected by a web
> > form saying that 'it is not a valid email address'. So I guess point
> > (17) can be extended to say that 'no email address shall end in anything
> > different that .com, .net or the local ccTLD'
> >
> > :=)
> >
> > Carlos
>
>
> Yea, I don't even know how programmers can get that wrong.  The regex
> is not even hard or anything.
>
>
>
> (?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])
>
>
I bet it's even harder without the use of a search engine.

Re: Whitelist of update servers

[Paul Graydon]

On 03/12/2012 10:53 AM, William Herrin wrote:

On Mon, Mar 12, 2012 at 4:40 PM, Peter Kristolaitis  wrote:

On 12-03-12 04:34 PM, Maverick wrote:

Like list of sites that operating systems or applications installed on
your machines go to update themselves. One way could be to go on each
vendors site and look at their update servers like
microsoft.update.com but it would be good if there is a list of such
servers for all OS and applications so that it could be used as a
whitelist.

I'm trying to determine if this is supposed to be an exercise in
"How To Annoy Your Sysadmins"
or
"How To Do Network Security The Really, Really Wrong Way"
or some combination of the two

Pete,

There are scenarios in which it is completely reasonable to provide
white listed Web access instead of general Internet access. Consider:
PCs in a prison with access to legal library and off-site education
web sites. It would be helpful if they could also access automatic
updates so they don't get malware but God help the sysadmin if one of
the prisoners figures out how to get to child porn.
But there are ways of doing that, such as Windows Software Update 
Services, and a little bit of policy enforcement from a centralised 
place.  That gives you a centralised, controlled place to push updates 
out from without risking the machines going off to the internet to get 
them themselves (and an opportunity to try limited roll-out just in case.)


For that matter if it's necessary to be talking about 
blacklisting/whitelisting sites under such conditions as PCs in a prison 
you're really better off just paying for something like a Websense to 
take care of it.


Paul

Re: Whitelist of update servers

[Peter Kristolaitis]

On 12-03-12 04:53 PM, William Herrin wrote:

On Mon, Mar 12, 2012 at 4:40 PM, Peter Kristolaitis  wrote:

On 12-03-12 04:34 PM, Maverick wrote:

Like list of sites that operating systems or applications installed on
your machines go to update themselves. One way could be to go on each
vendors site and look at their update servers like
microsoft.update.com but it would be good if there is a list of such
servers for all OS and applications so that it could be used as a
whitelist.

I'm trying to determine if this is supposed to be an exercise in
"How To Annoy Your Sysadmins"
or
"How To Do Network Security The Really, Really Wrong Way"
or some combination of the two

Pete,

There are scenarios in which it is completely reasonable to provide
white listed Web access instead of general Internet access. Consider:
PCs in a prison with access to legal library and off-site education
web sites. It would be helpful if they could also access automatic
updates so they don't get malware but God help the sysadmin if one of
the prisoners figures out how to get to child porn.

That having been said, this is almost certainly the wrong mailing list
to ask. It just isn't the kind of work we do here.

Regards,
Bill Herrin


In my experience, if you're dealing with a locked down environment like 
that, one or both of the following will be true:
- The users won't have sufficient privileges on the workstation to 
apply updates anyways

- Software updates and configuration changes are managed centrally

I agree that there are situations where whitelisted Web access might be 
suitable, but I expect the number of situations where you'd want 
whitelisted Web access AND ad-hoc software updates AND users to have 
local admin access on their workstations would be... very low.


- Pete

Re: Whitelist of update servers

[William Herrin]

On Mon, Mar 12, 2012 at 4:40 PM, Peter Kristolaitis  wrote:
> On 12-03-12 04:34 PM, Maverick wrote:
>> Like list of sites that operating systems or applications installed on
>> your machines go to update themselves. One way could be to go on each
>> vendors site and look at their update servers like
>> microsoft.update.com but it would be good if there is a list of such
>> servers for all OS and applications so that it could be used as a
>> whitelist.

> I'm trying to determine if this is supposed to be an exercise in
>    "How To Annoy Your Sysadmins"
> or
>    "How To Do Network Security The Really, Really Wrong Way"
> or some combination of the two

Pete,

There are scenarios in which it is completely reasonable to provide
white listed Web access instead of general Internet access. Consider:
PCs in a prison with access to legal library and off-site education
web sites. It would be helpful if they could also access automatic
updates so they don't get malware but God help the sysadmin if one of
the prisoners figures out how to get to child porn.

That having been said, this is almost certainly the wrong mailing list
to ask. It just isn't the kind of work we do here.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Whitelist of update servers

[Peter Kristolaitis]

I'm trying to determine if this is supposed to be an exercise in
"How To Annoy Your Sysadmins"
or
"How To Do Network Security The Really, Really Wrong Way"
or some combination of the two

- Pete



On 12-03-12 04:34 PM, Maverick wrote:

Like list of sites that operating systems or applications installed on
your machines go to update themselves. One way could be to go on each
vendors site and look at their update servers like
microsoft.update.com but it would be good if there is a list of such
servers for all OS and applications so that it could be used as a
whitelist.

On Mon, Mar 12, 2012 at 4:30 PM, Keegan Holley
  wrote:

2012/3/12 Maverick

Is there a whitelist that applications have to talk to in order to
update themselves?


sometimes

Re: Whitelist of update servers

[Keegan Holley]

2012/3/12 Maverick 

> Like list of sites that operating systems or applications installed on
> your machines go to update themselves. One way could be to go on each
> vendors site and look at their update servers like
> microsoft.update.com but it would be good if there is a list of such
> servers for all OS and applications so that it could be used as a
> whitelist.
>
>
I stick with my original answer... sometimes.  I'm not sure if this is
different now, but I remember MS update being spoofed with bogus DNS
entries because the process is died to that dns name.  I think this is the
most popular method combined with some sort of encryption and/or signing to
verify the updates themselves.  I'm sure there are applications that use a
white list though.  There are alot of shops that update via some kind of
CDN, so the whitelist method is a bit combersome at scale and is not immune
to spoofing or other attacks.  The most secure thing is probably to protect
the updates themselves.

Re: Whitelist of update servers

[Maverick]

Like list of sites that operating systems or applications installed on
your machines go to update themselves. One way could be to go on each
vendors site and look at their update servers like
microsoft.update.com but it would be good if there is a list of such
servers for all OS and applications so that it could be used as a
whitelist.

On Mon, Mar 12, 2012 at 4:30 PM, Keegan Holley
 wrote:
>
> 2012/3/12 Maverick 
>>
>> Is there a whitelist that applications have to talk to in order to
>> update themselves?
>>
> sometimes
>

Re: Whitelist of update servers

[goemon]

vague question gets vague answer.

"yes"

-Dan

On Mon, 12 Mar 2012, Maverick wrote:


Is there a whitelist that applications have to talk to in order to
update themselves?

Re: Whitelist of update servers

[Keegan Holley]

2012/3/12 Maverick 

> Is there a whitelist that applications have to talk to in order to
> update themselves?
>
> sometimes

Re: Whitelist of update servers

[Paul Graydon]

On 03/12/2012 10:05 AM, Maverick wrote:

Is there a whitelist that applications have to talk to in order to
update themselves?


Which applications? What updates?

Re: root zone stats

[-Hammer-]

Shouldn't "eh" be Canada and not Western Sahara?

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 3/12/2012 3:10 PM, Marco Davids (Prive) wrote:

On Mon, 12 Mar 2012, Marco Davids (Prive) wrote:


Some nice info here, too: http://bgp.he.net/report/dns



.cw seems to be missing.


Oops, it isn't... it's just not wehere I expected it.

--
Marco

Re: Whitelist of update servers

[-Hammer-]

Can you be a little more specific? Otherwise I think your answer would 
be "The Internet"


-Hammer-

"I was a normal American nerd"
-Jack Herer



On 3/12/2012 3:05 PM, Maverick wrote:

Is there a whitelist that applications have to talk to in order to
update themselves?

Re: Shim6, was: Re: filtering /48 is going to be necessary

[William Herrin]

On Mon, Mar 12, 2012 at 3:50 PM, Tim Chown  wrote:
> On 12 Mar 2012, at 19:30, Owen DeLong wrote:
>> I know my view is unpopular, but, I really would rather see
>>PI made inexpensive and readily available than see NAT
>>brought into the IPv6 mainstream. However, in my
>>experience, very few residential customers make
>>use of that 3G backup port.
>
> So what assumptions do you think future IPv6-enabled
>homenets might make about the prefixes they receive
>or can use?   Isn't having a PI per residential homenet
>rather unlikely?

Hi Tim,

Not at all. You just build a second tier to the routing system. BGP is
at the top tier. The second tier anchors SOHO users' provider
independent addresses to a dynamically mapped set of top-tier relay
addresses where each address in the relay anchor set can reach the
SOHO's IP. Then you put an entry relay at many/most ISPs which
receives the unrouted portions of PI space, looks up the exit relay
set and relays the packet.

The ingress relays have to keep some state but it's all discardable
(can be re-looked up at any time). Also, they can be pushed close
enough to the network edge that they aren't overwhelmed. The egress
relays are stateless.

Do it right and you get within a couple percent of the routing
efficiency of BGP for SOHOs with only two or three ISPs.

There are some issues with dead path detection which get thorny but
they're solvable. There's also an origin filtering problem: packets
originating from the PI space to BGP routed space aren't relayed and
the ISP doesn't necessarily need to know that one of the PA addresses
assigned to customer X is acting as an inbound relay for PI space.
Again: solvable.

If you want to dig in to how such a thing might work, read:
http://bill.herrin.us/network/trrp.html

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: US withdraws IANA RFP, ‘no suitable responses’

[Eric Brunner-Williams]

good head line copy edit.

body lacks substance, though not attitude.

-e

RE: root zone stats

[Marco Davids (Prive)]

On Mon, 12 Mar 2012, Marco Davids (Prive) wrote:


Some nice info here, too: http://bgp.he.net/report/dns



.cw seems to be missing.


Oops, it isn't... it's just not wehere I expected it.

--
Marco

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Owen DeLong]

On Mar 12, 2012, at 12:50 PM, Tim Chown wrote:

> 
> On 12 Mar 2012, at 19:30, Owen DeLong wrote:
> 
>> I know my view is unpopular, but, I really would rather see PI made 
>> inexpensive and readily available than see NAT brought into the IPv6 
>> mainstream. However, in my experience, very few residential customers make 
>> use of that 3G backup port.
> 
> So what assumptions do you think future IPv6-enabled homenets might make 
> about the prefixes they receive or can use?   Isn't having a PI per 
> residential homenet rather unlikely?
> 

Yes, but, having reasonable and/or multiple PA prefixes is very likely and 
there is no reason not to use that instead of cobbled solutions based on NPT.

> It would be desirable to avoid NPTv6 in the homenet scenario.
> 

Very much so. (Or any other scenario I can think of as well).

Owen

RE: root zone stats

[Marco Davids (Prive)]

On Sun, 11 Mar 2012, Frank Bulk wrote:


Some nice info here, too: http://bgp.he.net/report/dns


Nice, but... not 100% up to date?

.cw seems to be missing.

--
Marco



Frank

-Original Message-
From: Doug Barton [mailto:do...@dougbarton.us]
Sent: Saturday, March 10, 2012 5:14 PM
Cc: APNIC Mailing List; nanog@nanog.org
Subject: root zone stats

Since there was a question about this, some numbers:

Serial: 2012031001

Statistics
==
Number of root servers:   13
Roots with IPv6 glue:  9

Number of gTLDs:  22
Number of ccTLDs:249
Number of IDN TLDs:   42
Total number of TLDs:313

Number of IPv4 hosts:   1176
Number of IPv4 addresses:   1145

Number of IPv6 hosts:427
Number of IPv6 addresses:412
TLDs with IPv6 glue: 258

Total name server hosts:1177
Total NS addresses: 1557

Number of DS records:141
Number of TLDs with DS:   85


Enjoy,

Doug

--
   If you're never wrong, you're not trying hard enough

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Tim Chown]

On 12 Mar 2012, at 19:30, Owen DeLong wrote:

> I know my view is unpopular, but, I really would rather see PI made 
> inexpensive and readily available than see NAT brought into the IPv6 
> mainstream. However, in my experience, very few residential customers make 
> use of that 3G backup port.

So what assumptions do you think future IPv6-enabled homenets might make about 
the prefixes they receive or can use?   Isn't having a PI per residential 
homenet rather unlikely?

It would be desirable to avoid NPTv6 in the homenet scenario.

Tim

Re: Programmers with network engineering skills

[Tei]

On 12 March 2012 09:59, Carlos Martinez-Cagnazzo  wrote:
> Hey!
>
> On 3/8/12 8:24 PM, Lamar Owen wrote:
>> On Monday, March 05, 2012 09:36:41 PM Jimmy Hess wrote:
>> ...
>>>    (16)  The default gateway's IP address is always 192.168.0.1
>>>    (17) The user portion of E-mail addresses never contain special
>>> characters like  "-" "+"  "$"   "~"  "."  ",", "[",  "]"
> I've just had my ' xx AT cagnazzo.name' email address rejected by a web
> form saying that 'it is not a valid email address'. So I guess point
> (17) can be extended to say that 'no email address shall end in anything
> different that .com, .net or the local ccTLD'
>
> :=)
>
> Carlos


Yea, I don't even know how programmers can get that wrong.  The regex
is not even hard or anything.


(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])




-- 
--
ℱin del ℳensaje.

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Owen DeLong]

On Mar 12, 2012, at 11:53 AM, Seth Mos wrote:

> Hi,
> 
> Op 12 mrt 2012, om 18:09 heeft Owen DeLong het volgende geschreven:
> 
>>> +
>>> Cheap End Users
>>> =
>>> IPv6 NPt (IPv6 Prefix Translation)
>>> 
>>> Cheers,
>>> 
>>> Seth
>> 
>> I don't get the association between cheap end users and NPT. Can you explain 
>> how one relates to the other, given the added costs of unnecessarily 
>> translating prefixes?
> 
> Well, to explain cheap here I would like to explain it as following:
> 
> - The existing yumcha plastic soap box that you can buy at your local 
> electronics store is powerful enough. About as fast in v6 as it does v4 since 
> it is all software anyhow. It only gets faster from there.
> 

Right.

> - Requires no cooperation from the ISP. This gets excessively worse where n > 
> 1. Some have 8 or more for added bandwidth.
> 

This one doesn't really parse for me. I'm not sure I understand what you are 
saying.

> - The excessive cost associated by current ISP practices that demand you use 
> a business connection (at reduced bandwidth and increased cost). Somehow 
> there was a decision that you can't have PI on "consumer" connections.
> 

There's a big gap between PA without NPT and NPT, however.  At the consumer 
level, I'd rather go PA than NPT.

For a business, it's a different story, but, for a business, PI seems feasible 
and I would think that the business connection is sort of a given.

> - Traffic engineering is a cinch, since it is all controlled by the single 
> box. For example round robin the connections for increased download speed. 
> Similar to how we do it in v4 land.
> 

With all the same dysfunction. Further, in v4 land this depends a great deal on 
support built into applications and ALGs and a lot of other bloat and hacking 
to glue the broken little pieces back together and make it all work. I'm truly 
hoping that we can move away from that in IPv6.

I'd really like to see application developers free to develop robust networking 
code in their applications instead of having to focus all their resources on 
dealing with the perils and pitfalls of NAT environments.

> - It is mighty cheap to implement in current software, a number of Cisco and 
> Jumiper releases support it. The various *bsd platforms do and linux is in 
> development.

Well, I guess that depends on how and where you measure cost. Sure, if you only 
count the cost of making the capability available in the feature set on the 
router, it's cheap and easy. If you count the cost and overhead of the 
application bloat and complexity and the support costs, the security costs, 
etc. it adds up pretty quickly.

Sort of like it doesn't cost much to send spam, but, the cost of dealing with 
the never ending onslaught of unwanted email seems to go up every year. (Yes, I 
just compared people using NPT to spammers).

> - Not to underestimate the failover capabilities when almost all routers 
> support 3G dongles for backup internet these days.
> 

If you care that much about failover, PI is a much better solution.

I know my view is unpopular, but, I really would rather see PI made inexpensive 
and readily available than see NAT brought into the IPv6 mainstream. However, 
in my experience, very few residential customers make use of that 3G backup 
port.

> There are considerable drawbacks ofcourse:
> 
> - Rewriting prefixes breaks voip/ftp again although without the port 
> rewriting the impact is less, but significant. I'd really wish that h323, ftp 
> and voip would go away. Or other protocols the embed local IP information 
> inside the datagram. But I digress.
> 

Yep.

> - People balk at the idea of NAT66, not to underestimate a very focal group 
> here. All for solutions here. :-)
> 

For good reason!

> - It requires keeping state, so no graceful failover. This means dropping 
> sessions ofcourse but the people that want this likely won't care for the 
> price they are paying.
> 

True.

> Probably missed a bunch of arguments the people will complain about. It is 
> probably best explained in the current experimental draft for NPt.
> http://tools.ietf.org/html/rfc6296

More than likely. Hopefully we can stop trying so hard to break the internet 
and start working on ways to make it better soon.


Owen

Re: Shim6, was: Re: filtering /48 is going to be necessary

[William Herrin]

On Mon, Mar 12, 2012 at 11:31 AM, Leo Bicknell  wrote:
> In a message written on Mon, Mar 12, 2012 at 11:07:54AM -0400, Robert E. 
> Seastrom wrote:
>> Grass-roots, bottom-up policy process
>> +
>> Need for multihoming
>> +
>> Got tired of waiting
>> =
>> IPv6 PI
>
> It was never clear to me that even if it worked 100% as advertised that
> it would be cheaper / better in the global sense.

Hi Leo,

When I ran the numbers a few years ago, a route had a global cost
impact in the neighborhood of $8000/year. It's tough to make a case
that folks who need multihoming's reliability can't afford to put that
much into the system. As long as the system is largely restricted to
folks who do put that much in, there's really no "problem" with the
current flood-all-routers multihoming strategy: at $8k/year the demand
will never again exceed the supply.

A *working* multi-addressed end user system (like shim6 attempted)
could solve cheap multihoming. That could have a billion dollar a year
impact as folks at the leaf nodes decide they don't need the more
costly BGP multihoming. But that's not where the real money is.

Often overlooked is that multihoming through multi-addressing could
solve IP mobility too. Provider-agnostic and media-agnostic mobility
without levering off a "home" router. That's where the money is. Carry
your voip call uninterrupted from your home wifi on the cable modem to
your cell provider in the car to your employer's wired ethernet and
back. Keep your SSH sessions alive on the notebook as you travel from
home, to the airport, to London and to the hotel. Let folks access the
web server on your notebook as it travels from home, to the airport,
to Tokyo and back.

The capability doesn't exist today. The potential economic impact of
such a capability's creation is unbounded.

Unfortunately, shim6 didn't work in some of the boundary cases. Since
single-homing works pretty well in the ordinary case, there's not much
point to a multihoming protocol that fails to deliver all the boundary
cases. IIRC, the main problem was that they tried to bootstrap the
layer 3 to layer 2 mapping function instead of externally requesting
it. That's like trying to build ARP by making a unicast request to a
local router instead of a broadcast/multicast request on the LAN. What
happens when the local routers no longer have MAC addresses that you
know about? Fail.

Also, in complete fairness, shim6 suffered for the general lack of
consumer interest in IPv6 that persists even today. It's proponents
bought in to the hype that new work should focus on IPv6, and they
paid for it.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Robert E. Seastrom]

Ryan Malayter  writes:

> On Mar 12, 10:07 am, "Robert E. Seastrom"  wrote:
>> It didn't help that there was initially no implementation of shim6
>> whatsoever.  That later turned into a single prototype implementation
>> of shim6 for linux.  As much as I tried to keep an open mind about
>> shim6, eventually it became clear that this was a Gedankenexperiment
>> in protocol design.  Somewhere along the line I started publicly
>> referring to it as "sham6".  I'm sure I'm not the only person who came
>> to that conclusion.
>>
>
> I thought the IETF required two inter-operable implementations for
> protocols. Or was that just for standards-track stuff?

Rough consensus and working code is soo 1993.

-r

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Seth Mos]

Hi,

Op 12 mrt 2012, om 18:09 heeft Owen DeLong het volgende geschreven:

>> +
>> Cheap End Users
>> =
>> IPv6 NPt (IPv6 Prefix Translation)
>> 
>> Cheers,
>> 
>> Seth
> 
> I don't get the association between cheap end users and NPT. Can you explain 
> how one relates to the other, given the added costs of unnecessarily 
> translating prefixes?

Well, to explain cheap here I would like to explain it as following:

- The existing yumcha plastic soap box that you can buy at your local 
electronics store is powerful enough. About as fast in v6 as it does v4 since 
it is all software anyhow. It only gets faster from there.

- Requires no cooperation from the ISP. This gets excessively worse where n > 
1. Some have 8 or more for added bandwidth.

- The excessive cost associated by current ISP practices that demand you use a 
business connection (at reduced bandwidth and increased cost). Somehow there 
was a decision that you can't have PI on "consumer" connections.

- Traffic engineering is a cinch, since it is all controlled by the single box. 
For example round robin the connections for increased download speed. Similar 
to how we do it in v4 land.

- It is mighty cheap to implement in current software, a number of Cisco and 
Jumiper releases support it. The various *bsd platforms do and linux is in 
development.

- Not to underestimate the failover capabilities when almost all routers 
support 3G dongles for backup internet these days.

There are considerable drawbacks ofcourse:

- Rewriting prefixes breaks voip/ftp again although without the port rewriting 
the impact is less, but significant. I'd really wish that h323, ftp and voip 
would go away. Or other protocols the embed local IP information inside the 
datagram. But I digress.

- People balk at the idea of NAT66, not to underestimate a very focal group 
here. All for solutions here. :-)

- It requires keeping state, so no graceful failover. This means dropping 
sessions ofcourse but the people that want this likely won't care for the price 
they are paying.

Probably missed a bunch of arguments the people will complain about. It is 
probably best explained in the current experimental draft for NPt.
http://tools.ietf.org/html/rfc6296

Cheers,

Seth

US withdraws IANA RFP, ‘no suitable responses’

[Henry Linneweh]

http://www.theregister.co.uk/2012/03/11/icann_loses_one_horse_race/

-Henry

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Darrel Lewis]

On Mar 11, 2012, at 3:15 PM, Iljitsch van Beijnum wrote:

> On 11 Mar 2012, at 20:15 , Joel jaeggli wrote:
> 
>>> The IETF and IRTF have looked at the routing scalability issue for a
>>> long time. The IETF came up with shim6, which allows multihoming
>>> without BGP. Unfortunately, ARIN started to allow IPv6 PI just in
>>> time so nobody bothered to adopt shim6.
> 
>> That's a fairly simplistic version of why shim6 failed. A better reason
>> (appart from the fact the building an upper layer overlay of the whole
>> internet on an ip protocol that's largely unedeployed was hard) is that
>> it leaves the destination unable to perform traffic engineering.
> 
> I'm not saying that shim6 would have otherwise ruled the world by now, it was 
> always an uphill battle because it requires support on both sides of a 
> communication session/association.
> 
> But ARIN's action meant it never had a chance. I really don't get why they 
> felt the need to start allowing IPv6 PI after a decade, just when the 
> multi6/shim6 effort started to get going but before the work was complete 
> enough to judge whether it would be good enough.
> 
>> That fundementaly is the business we're in when advertising prefixes to more
>> than one provider, ingress path selection.
> 
> That's the business network operators are in. That's not the business end 
> users who don't want to depend on a single ISP are in. Remember, shim6 was 
> always meant as a solution that addresses the needs of a potential 1 billion 
> "basement multihomers" with maybe ADSL + cable. The current 25k or so 
> multihomers are irrelevant from the perspective of routing scalability. It's 
> the other 999,975,000 that will kill the routing tables if multihoming 
> becomes mainstream.


When discussing 'why shim6 failed' I think its only fair to include a link to a 
(well reasoned, imho) network operator's perspective on what it did and did not 
provide in the way of capabilities that network operators desired.

http://www.nanog.org/meetings/nanog35/abstracts.php?pt=NDQ3Jm5hbm9nMzU=&nm=nanog35

-Darrel

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Owen DeLong]

On Mar 12, 2012, at 8:56 AM, Iljitsch van Beijnum wrote:

> On 12 Mar 2012, at 16:21 , Leigh Porter wrote:
> 
>>> Grass-roots, bottom-up policy process
>>> +
>>> Need for multihoming
>>> +
>>> Got tired of waiting
>>> =
>>> IPv6 PI
> 
>> A perfect summation.
> 
> Except that it didn't happen in that order. When ARIN approved PI the shim6 
> effort was well underway, but it was too early to be able to know to what 
> degree it would solve the multihoming problem. Earlier, when multi6 was stuck 
> or later, when shim6, at least as a specification, but preferably as multiple 
> implementations, could have been evaluated would both have been reasonable 
> times to decide to go for PI instead.
> 
> Of course as has been the case over and over the argument "if you give us 
> feature X we'll implement IPv6" has never borne out.
> 

Except it didn't happen that way.

The argument wasn't "If you give us PI, we'll implement IPv6."

The argument that carried the day and is, IMHO, quite valid was "If you don't 
give us PI we definitely WON'T implement IPv6."

The inability to obtain PI was a serious detractor from IPv6 for any 
organization that already had IPv4 PI. Shim6 showed no promise whatsoever of 
changing this even in its most optimistic marketing predictions at the time. 
(As you point out, it was well underway at that point and it's not as if we 
didn't look at it prior to drafting the policy proposal.)

Frankly, I think the long term solution is to implement IDR based on Locators  
in the native packet header and not using map/encap schemes that reduce MTU, 
but that doesn't seem to be a popular idea so far.

>> Also given that people understand what PI space is and how it works and 
>> indeed it does pretty much just work for the end users of the space.
> 
> The trouble is that it doesn't scale. Which is fine right now at the current 
> IPv6 routing table size, but who knows what the next decades bring. We've 
> been living with IPv4 for 30 years now, and IPv6 doesn't have a built-in 
> 32-bit expiry date so it's almost certainly going to be around for much 
> longer.

If IPv6 works out in the 1.6-2:1 prefix:ASN ratio that I expect or even as much 
as 4:1, we'll get at least another 30 years out of it. Since we've had IPv6 now 
for about 15 years, it's already half way through that original 30. :p

Owen

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Owen DeLong]

On Mar 12, 2012, at 8:23 AM, Seth Mos wrote:

> On 12-3-2012 16:07, Robert E. Seastrom wrote:
>> 
>> Doug Barton  writes:
>> 
> 
>> Grass-roots, bottom-up policy process
>> +
>> Need for multihoming
>> +
>> Got tired of waiting
>> =
>> IPv6 PI
> 
> +
> Cheap End Users
> =
> IPv6 NPt (IPv6 Prefix Translation)
> 
> Cheers,
> 
> Seth

I don't get the association between cheap end users and NPT. Can you explain 
how one relates to the other, given the added costs of unnecessarily 
translating prefixes?

Owen

Ciena CN4200 documentation

[Brian Talley]

Does anyone have a user manual and/or configuration guide for a Ciena
CN4200?  I tried contacting their technical publication phone number and
email but never heard back.  If anyone has anything that's more in-depth
than marketing material, please contact me off-list.  I'm primarily
interested in how to troubleshoot "loss of frame" messages and what the
front panel LED states mean, but anything will help.

TIA,
BT

-- 
Brian Talley
Network Engineer
btal...@photobucket.com

Re: Programmers with network engineering skills

[Carlos Martinez-Cagnazzo]

Hey!

On 3/8/12 8:24 PM, Lamar Owen wrote:
> On Monday, March 05, 2012 09:36:41 PM Jimmy Hess wrote:
> ...
>>(16)  The default gateway's IP address is always 192.168.0.1
>>(17) The user portion of E-mail addresses never contain special
>> characters like  "-" "+"  "$"   "~"  "."  ",", "[",  "]"
I've just had my ' xx AT cagnazzo.name' email address rejected by a web
form saying that 'it is not a valid email address'. So I guess point
(17) can be extended to say that 'no email address shall end in anything
different that .com, .net or the local ccTLD'

:=)

Carlos

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Ryan Malayter]

On Mar 12, 10:07 am, "Robert E. Seastrom"  wrote:
> It didn't help that there was initially no implementation of shim6
> whatsoever.  That later turned into a single prototype implementation
> of shim6 for linux.  As much as I tried to keep an open mind about
> shim6, eventually it became clear that this was a Gedankenexperiment
> in protocol design.  Somewhere along the line I started publicly
> referring to it as "sham6".  I'm sure I'm not the only person who came
> to that conclusion.
>

I thought the IETF required two inter-operable implementations for
protocols. Or was that just for standards-track stuff?

Anyway, the effort involved in getting Shim6 implemented globally on
all devices would have been nearly as large as switching over all
applications from TCP to a protocol with a "proper" session layer,
like SCTP. I believe there are libraries that wrap SCTP and make it
look like TCP to legacy applications; wouldn't that have been a better
approach?

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Iljitsch van Beijnum]

On 12 Mar 2012, at 16:21 , Leigh Porter wrote:

>> Grass-roots, bottom-up policy process
>> +
>> Need for multihoming
>> +
>> Got tired of waiting
>> =
>> IPv6 PI

> A perfect summation.

Except that it didn't happen in that order. When ARIN approved PI the shim6 
effort was well underway, but it was too early to be able to know to what 
degree it would solve the multihoming problem. Earlier, when multi6 was stuck 
or later, when shim6, at least as a specification, but preferably as multiple 
implementations, could have been evaluated would both have been reasonable 
times to decide to go for PI instead.

Of course as has been the case over and over the argument "if you give us 
feature X we'll implement IPv6" has never borne out.

> Also given that people understand what PI space is and how it works and 
> indeed it does pretty much just work for the end users of the space.

The trouble is that it doesn't scale. Which is fine right now at the current 
IPv6 routing table size, but who knows what the next decades bring. We've been 
living with IPv4 for 30 years now, and IPv6 doesn't have a built-in 32-bit 
expiry date so it's almost certainly going to be around for much longer.

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Leo Bicknell]

In a message written on Mon, Mar 12, 2012 at 11:07:54AM -0400, Robert E. 
Seastrom wrote:
> Grass-roots, bottom-up policy process
> +
> Need for multihoming
> +
> Got tired of waiting
> =
> IPv6 PI

I'll also add that Shim6 folks never made a good economic argument.
It's true that having routes in the DFZ costs money, and that
reducing the number of routes will save the industry money in router
upgrades and such to handle more routes.  However, it's also true
that deploying SHIM6 (or similar solutions) also has a cost in
rewritten software, traning for network engineers and administrators,
and so on.

It was never clear to me that even if it worked 100% as advertised that
it would be cheaper / better in the global sense.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpeb1SyIUvLc.pgp
Description: PGP signature

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Seth Mos]

On 12-3-2012 16:07, Robert E. Seastrom wrote:
> 
> Doug Barton  writes:
> 

> Grass-roots, bottom-up policy process
> +
> Need for multihoming
> +
> Got tired of waiting
> =
> IPv6 PI

+
Cheap End Users
=
IPv6 NPt (IPv6 Prefix Translation)

Cheers,

Seth

Re: filtering /48 is going to be necessary

[Jared Mauch]

The big issue is not the control plane but forwarding plane memory. SRAM is hot 
and expensive. 

Jared Mauch

On Mar 10, 2012, at 5:50 PM, Sven Olaf Kamphuis  wrote:

> you did buy a new iphone i bet.. why no modern routers.

RE: Shim6, was: Re: filtering /48 is going to be necessary

[Leigh Porter]

> 
> Grass-roots, bottom-up policy process
> +
> Need for multihoming
> +
> Got tired of waiting
> =
> IPv6 PI
> 
> -r

A perfect summation. Also given that people understand what PI space is and how 
it works and indeed it does pretty much just work for the end users of the 
space.

--
Leigh Porter
UK Broadband


__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__

Re: Shim6, was: Re: filtering /48 is going to be necessary

[Robert E. Seastrom]

Doug Barton  writes:

> On 3/11/2012 3:15 PM, Iljitsch van Beijnum wrote:
>> But ARIN's action meant it never had a chance. I really don't get why they 
>> felt the need to start allowing IPv6 PI after a decade
>
> Because as far back as 2003 ARIN members (and members from all the other
> RIRs for that matter) were saying in very clear terms that PI space was
> a requirement for moving to v6. No one wanted to lose the provider
> independence that they had gained with v4. Without that, v6 was a total
> non-starter.
>
> ARIN was simply listening to its members.

It didn't help that there was initially no implementation of shim6
whatsoever.  That later turned into a single prototype implementation
of shim6 for linux.  As much as I tried to keep an open mind about
shim6, eventually it became clear that this was a Gedankenexperiment
in protocol design.  Somewhere along the line I started publicly
referring to it as "sham6".  I'm sure I'm not the only person who came
to that conclusion.

Grass-roots, bottom-up policy process
+
Need for multihoming
+
Got tired of waiting
=
IPv6 PI

-r

Re: [apnic-talk] Concern about gTLD servers in India

[Che-Hoo CHENG]

J root should be j.root-servers.net (192.58.128.30).

Che-Hoo


On 12 Mar, 2012, at 5:09 PM, Anurag Bhatia wrote:

> Just looked at j root in detail.
> 
> 
> Unfortunately not much of traffic is going to J root. BSNL along with its 
> main upstream providers Tata & Airtel - all picking outside routes. Tata 
> AS4755 is taking directly to AS6453 while AS6453 is passing to NTT in London 
> which is next taking back to Japan and then going to HK anycasted node (yeah 
> head shake routing!).
> 
> 
> Here's a view:
> 
> traceroute to j.gtld-servers.net (192.48.79.30), 30 hops max, 60 byte packets
>  1  router.local (192.168.1.1) [AS8151/AS28513]  1.180 ms  1.621 ms  2.121 ms
>  2  117.207.48.1 (117.207.48.1) [AS9829]  26.935 ms  29.328 ms  31.956 ms
>  3  218.248.173.46 (218.248.173.46) [AS9829]  34.393 ms  37.093 ms *
>  4  115.114.57.165.static-Mumbai.vsnl.net.in (115.114.57.165) [AS4755]  
> 74.623 ms  78.281 ms  82.352 ms
>  5  if-0-100.tcore2.MLV-Mumbai.as6453.net (180.87.39.25) [*]  299.987 ms  
> 300.397 ms  314.175 ms
>  6  if-6-2.tcore1.L78-London.as6453.net (80.231.130.5) [AS6453]  314.573 ms  
> 264.576 ms  261.030 ms
>  7  Vlan704.icore1.LDN-London.as6453.net (80.231.130.10) [AS6453]  279.896 ms 
>  280.312 ms *
>  8  Vlan522.icore1.LDN-London.as6453.net (195.219.83.22) [AS6453]  333.651 ms 
>  326.233 ms  330.307 ms
>  9  ae-4.r23.londen03.uk.bb.gin.ntt.net (129.250.5.40) [AS2914]  323.084 ms  
> 324.204 ms  329.300 ms
> 10  as-0.r22.osakjp01.jp.bb.gin.ntt.net (129.250.5.35) [AS2914]  457.845 ms  
> 459.011 ms  456.842 ms
> 11  as-0.r20.newthk02.hk.bb.gin.ntt.net (129.250.2.7) [AS2914]  495.869 ms  
> 495.615 ms  496.840 ms
> 12  ae-1.r02.chwahk02.hk.bb.gin.ntt.net (129.250.3.131) [AS2914]  476.471 ms  
> 478.525 ms  478.104 ms
> 13  * * *
> 14  * * *
> 15  * * *
> 
> 
> 
> 
> Router: gin-mlv-core1 
> Site: IN, Mumbai - MLV, VSNL 
> Command: show ip bgp 192.48.79.30
> 
> 
> BGP routing table entry for 192.48.79.0/24
> Bestpath Modifiers: deterministic-med
> Paths: (3 available, best #2)
> Multipath: eBGP
>   2914 36631 36631, (aggregated by 36631 203.131.245.40)
> ldn-icore1. (metric 2991) from mlv-tcore1. (66.110.10.202)
>   Origin IGP, valid, internal
>   Community: 
>   Originator: ldn-icore1.
>   2914 36631 36631, (aggregated by 36631 203.131.245.40)
> ldn-icore1. (metric 2991) from cxr-tcore1. (66.110.10.113)
>   Origin IGP, valid, internal, best
>   Community: 
>   Originator: ldn-icore1.
>   2914 36631 36631, (aggregated by 36631 203.131.245.40)
> ldn-icore1. (metric 2991) from mlv-tcore2. (66.110.10.215)
>   Origin IGP, valid, internal
>   Community: 
>   Originator: ldn-icore1.
> 
> 
> Path via NTT in all cases.
> 
> So Mumbai - London - Japan - HongKong. Very likely because of same old 
> problem I mentioned - Tata peers with NTT in London but not Japan. 
> 
> anurag@laptop:~$ dig j.gtld-servers.net a +short
> 192.48.79.30
> 
> 
> anurag@laptop:~$ awhois 192.48.79.30
> AS  | IP   | BGP Prefix  | CC | AS Name
> 36631   | 192.48.79.30 | 192.48.79.0/24  | US | ZGTLD - VeriSign 
> Global Registry Services
> 
> 
> http://bgp.he.net/AS36631#_peers
> 
> 
> 
> 
> And situation for Airtel isn't better at all for J root. Instead of picking 
> NTT, they are using Packnet/AsiaNetcom because Packnet is likely a client of 
> Hurricane Electric and Airtel peers with HE.
> 
> Mon Mar 12 14:22:49 GMT+05:30 2012
> traceroute 192.48.79.30
> 
> Type escape sequence to abort.
> Tracing the route to j.gtld-servers.net (192.48.79.30)
> 
>   1 59.145.6.149 [MPLS: Label 800 Exp 0] 288 msec
> 59.145.6.145 [MPLS: Label 800 Exp 0] 284 msec
> 59.145.0.181 [MPLS: Label 1668 Exp 0] 260 msec
>   2 202.56.223.50 [MPLS: Label 308480 Exp 0] 256 msec 256 msec
> 202.56.223.205 [MPLS: Label 311696 Exp 0] 276 msec
>   3 182.79.220.198 [MPLS: Label 1795 Exp 0] 276 msec 276 msec
> 182.79.252.161 [MPLS: Label 1795 Exp 0] 272 msec
>   4 AES-Static-122.36.144.59.airtel.in (59.144.36.122) 272 msec 272 msec 288 
> msec
>   5 he.net.coresite.com (206.223.143.122) 288 msec 292 msec 272 msec
>   6 10gigabitethernet2-1.core1.lax1.he.net (72.52.92.121) [AS 6939] 272 msec 
> 276 msec 288 msec
>   7 pacnet.10gigabitethernet2-3.core1.lax1.he.net (216.218.223.206) [AS 6939] 
> 288 msec 288 msec 272 msec
>   8 te0-1-0-0.wr1.nrt0.asianetcom.net (61.14.157.89) [AS 10026] 264 msec 264 
> msec 284 msec
>   9 te0-0-4-0.wr2.nrt0.asianetcom.net (61.14.157.14) [AS 10026] [MPLS: Label 
> 16191 Exp 0] 288 msec 292 msec 276 msec
>  10 te0-0-0-0.wr2.osa0.asianetcom.net (61.14.157.2) [AS 10026] [MPLS: Label 
> 16002 Exp 0] 276 msec 300 msec 292 msec
>  11 te0-0-4-0.wr1.osa0.asianetcom.net (61.14.157.21) [AS 10026] 292 msec 292 
> msec 276 msec
>  12 te0-1-0-0.wr1.hkg0.asianetcom.net (61.14.157.57) [AS 10026] 272 msec 268 
> msec 288 msec
>  13 ge-4-1-0-0.cr4.hkg3.asianetcom.net (61.14.157.142) [AS 10026] 284 msec 
> 288 msec 264 msec
>  14 te3-2.gw1.hkg4.asianet

Concern about gTLD servers in India

[Anurag Bhatia]

Just looked at j root in detail.


Unfortunately not much of traffic is going to J root. BSNL along with its
main upstream providers Tata & Airtel - all picking outside routes. Tata
AS4755 is taking directly to AS6453 while AS6453 is passing to NTT in
London which is next taking back to Japan and then going to HK anycasted
node (yeah head shake routing!).


Here's a view:

traceroute to j.gtld-servers.net (192.48.79.30), 30 hops max, 60 byte
packets
 1  router.local (192.168.1.1) [AS8151/AS28513]  1.180 ms  1.621 ms  2.121
ms
 2  117.207.48.1 (117.207.48.1) [AS9829]  26.935 ms  29.328 ms  31.956 ms
 3  218.248.173.46 (218.248.173.46) [AS9829]  34.393 ms  37.093 ms *
 4  
115.114.57.165.static-Mumbai.vsnl.net.in
(115.114.57.165)
[AS4755]  74.623 ms  78.281 ms  82.352 ms
 5  if-0-100.tcore2.MLV-Mumbai.as6453.net (180.87.39.25) [*]  299.987 ms
 300.397 ms  314.175 ms
 6  if-6-2.tcore1.L78-London.as6453.net (80.231.130.5) [AS6453]  314.573 ms
 264.576 ms  261.030 ms
 7  
Vlan704.icore1.LDN-London.as6453.net
 (80.231.130.10) [AS6453]  279.896 ms  280.312 ms *
 8  
Vlan522.icore1.LDN-London.as6453.net
(195.219.83.22)
[AS6453]  333.651 ms  326.233 ms  330.307 ms
 9  ae-4.r23.londen03.uk.bb.gin.ntt.net (129.250.5.40) [AS2914]  323.084 ms
 324.204 ms  329.300 ms
10  as-0.r22.osakjp01.jp.bb.gin.ntt.net (129.250.5.35) [AS2914]  457.845 ms
 459.011 ms  456.842 ms
11  as-0.r20.newthk02.hk.bb.gin.ntt.net (129.250.2.7) [AS2914]  495.869 ms
 495.615 ms  496.840 ms
12  ae-1.r02.chwahk02.hk.bb.gin.ntt.net (129.250.3.131) [AS2914]  476.471
ms  478.525 ms  478.104 ms
13  * * *
14  * * *
15  * * *




*Router:* gin-mlv-core1
*Site:* IN, Mumbai - MLV, VSNL
*Command:* show ip bgp 192.48.79.30


BGP routing table entry for *192.48.79.0/24*
Bestpath Modifiers: deterministic-med
Paths: (3 available, best #2)
Multipath: eBGP
  2914 36631 36631, (aggregated by 36631 203.131.245.40)
ldn-icore1. (metric 2991) from mlv-tcore1. (66.110.10.202)
  Origin IGP, valid, internal
  Community:
  Originator: ldn-icore1.  2914 36631 36631, (aggregated by 36631
203.131.245.40)ldn-icore1. (metric 2991) from cxr-tcore1.
(66.110.10.113)  Origin IGP, valid, internal, best  Community:
  Originator: ldn-icore1.
  2914 36631 36631, (aggregated by 36631 203.131.245.40)
ldn-icore1. (metric 2991) from mlv-tcore2. (66.110.10.215)
  Origin IGP, valid, internal
  Community:
  Originator: ldn-icore1.



Path via NTT in all cases.

So Mumbai - London - Japan - HongKong. Very likely because of same old
problem I mentioned - Tata peers with NTT in London but not Japan.

anurag@laptop:~$ dig j.gtld-servers.net a +short
192.48.79.30


anurag@laptop:~$ awhois 192.48.79.30
AS  | IP   | BGP Prefix  | CC | AS Name
36631   | 192.48.79.30 | 192.48.79.0/24  | US | ZGTLD - VeriSign
Global Registry Services


http://bgp.he.net/AS36631#_peers




And situation for Airtel isn't better at all for J root. Instead of picking
NTT, they are using Packnet/AsiaNetcom because Packnet is likely a client
of Hurricane Electric and Airtel peers with HE.

Mon Mar 12 14:22:49 GMT+05:30 2012
traceroute 192.48.79.30

Type escape sequence to abort.
Tracing the route to j.gtld-servers.net (192.48.79.30)

  1 59.145.6.149 [MPLS: Label 800 Exp 0] 288 msec
59.145.6.145 [MPLS: Label 800 Exp 0] 284 msec
59.145.0.181 [MPLS: Label 1668 Exp 0] 260 msec
  2 202.56.223.50 [MPLS: Label 308480 Exp 0] 256 msec 256 msec
202.56.223.205 [MPLS: Label 311696 Exp 0] 276 msec
  3 182.79.220.198 [MPLS: Label 1795 Exp 0] 276 msec 276 msec
182.79.252.161 [MPLS: Label 1795 Exp 0] 272 msec
  4 
AES-Static-122.36.144.59.airtel.in
(59.144.36.122)
272 msec 272 msec 288 msec
  5 he.net.coresite.com (206.223.143.122) 288 msec 292 msec 272 msec
  6 10gigabitethernet2-1.core1.lax1.he.net (72.52.92.121) [AS 6939] 272
msec 276 msec 288 msec
  7 pacnet.10gigabitethernet2-3.core1.lax1.he.net (216.218.223.206) [AS
6939] 288 msec 288 msec 272 msec
  8 te0-1-0-0.wr1.nrt0.asianetcom.net (61.14.157.89) [AS 10026] 264 msec
264 msec 284 msec
  9 te0-0-4-0.wr2.nrt0.asianetcom.net (61.14.157.14) [AS 10026] [MPLS:
Label 16191 Exp 0] 288 msec 292 msec 276 msec
 10 te0-0-0-0.wr2.osa0.asianetcom.net (61.14.157.2) [AS 10026] [MPLS: Label
16002 Exp 0] 276 msec 300 msec 292 msec
 11 te0-0-4-0.wr1.osa0.asianetcom.net (61.14.157.21) [AS 10026] 292 msec
292 msec 276 msec
 12 te0-1-0-0.wr1.hkg0.asianetcom.net (61.14.157.57) [AS 10026] 272 msec
268 msec 288 msec
 13 ge-4-1-0-0.cr4.hkg3.asianetcom.net (61.14.157.142) [AS 10026] 284 msec
288 msec 264 msec
 14 te3-2.gw1.hkg4.asianetcom.net (202.147.16.198) [AS 10026] 336 msec 264
msec 284 msec
 15 VNB-0025.gw1.hkg4.asianetcom.net
(203.192.137.78)
[AS 10026] 284 msec 288 msec 268 msec
 1

Re: Questions about anycasting setup

[Elmar K. Bins]

Morn' Steve,

s...@gibbard.org (Steve Gibbard) wrote:

> I have no idea what Cisco equipment Elmar is using, but I wouldn't jump to 
> the conclusion that it can't withdraw routes when needed.

We use scripts external to both the routing platform and the
service delivery platform to check the service and reconfigure
L3 equipment (which is all kinds of L3 capable hardware).

Elmar.

Re: filtering /48 is going to be necessary

[Masataka Ohta]

Joel jaeggli wrote:

> That's a fairly simplistic version of why shim6 failed. A better reason
> (appart from the fact the building an upper layer overlay of the whole
> internet on an ip protocol that's largely unedeployed was hard) is that

Shim6 failed mostly because of its complexity.

It is complex mostly because its architecture is broken,
trying to hide existence of shim6 from applications (the end
systems within end hosts), which is against the end to end
principle and impossible, only to make application
modifications even more complicated.

Other added features makes shim6 even worse.

> it leaves the destination unable to perform traffic engineering. That
> fundementaly is the business we're in when advertising prefixes to more
> than one provider, ingress path selection.

That's not a inherent problem of architectures with multiple
addresses.

Destination hosts can listen to advertisements of destination
network administrators and suggest source hosts which prefixes
are preferred by the administrators.

That is the end to end way of destination traffic engineering
without bloating routing table entries.

Masataka Ohta