Re: Quarantine your infected users spreading malware

[Christopher L. Morrow]

On Wed, 1 Mar 2006, Jack Bates wrote:

> Christopher L. Morrow wrote:
> 
> > agreed, punting this problem to the helpdesk makes the helpdesk manager
> > grab his gun(s) and find the security wonk that put a hurtin' on his
> > numbers :) Also, it costs lots of money, which isn't generally a good
> > plan.
>
> Do you find that web redirection actually stems the flow of calls to the
> helpdesk? We find that anything out of the normal usually results in a

don't know, we don't do it except for some internal things I think... I
just know what our customer support folks do if I screw up and make a
bunch of customers call in :)

Re: Shim6 vs PI addressing

[Andre Oppermann]

Owen DeLong wrote:

Please don't mix up addressing and routing. "PI addressing" as you
mention is addressing. SHIM6 will become a routing trick.



I think that is overly pessimistic.  I would say that SHIM6 _MAY_
become a routing trick, but, so far, SHIM6 is a still-born piece
of overly complicated vaporware of minimal operational value, if any.

Personally, I think a better solution is to stop overloading IDR
meaning onto IP addresses and use ASNs for IDR and prefixes for
intradomain routing only.


Full ACK!  For the IDR we then can use perfect match lookups which
scale very well and pretty cheaply to many millions of table entries.
BGP scales very well too if you've got a decent cpu in your router.
Our OpenBGPD easily does 30 flapping constandly full-feeds with 1 million
routes each.

Lets get pragmatic and realistic!

--
Andre

Re: shim6 @ NANOG (forwarded note from John Payne)

[Michael . Dillon]

> >  The scope of 
> > that policy mediation function depends strongly on
> > people like you 
> > saying "at a high level, this is the kind of
> > decision I am not happy 
> > with the hosts making".
> 
> Resounding YES - I specifically DON'T want end-hosts
> to be able to make these decisions, but need to be
> able to multihome.

When I see comments like this I wonder whether people
understand what shim6 is all about. First of all, these
aren't YOUR hosts. They belong to somebody else. If you
are an access provider then these hosts belong to a customer
that is paying you to carry packets. This customer also
pays another ISP for the same service and the hosts
are making decisions about whether to use your service
or your competitors. 

If you are a hosting provider, then these hosts, owned 
by a third party, are making decisions about whether to
send you packets through one or another AS.

Is there something inherently wrong with independent
organizations deciding where to send their packets?

--Michael Dillon

P.S. I don't believe that shim6 will ever succeed.

Re: shim6 @ NANOG (forwarded note from John Payne)

[Stephen Sprunk]

Thus spake "Joe Abley" <[EMAIL PROTECTED]>

On 1-Mar-2006, at 11:55, David Barak wrote:

It isn't fearing change to ask the question "it's not
broken today, why should I fix it?"


What's broken today is that there's no mechanism available for people  who 
don't qualify for v6 PI space to multi-home. That's what shim6 is  trying 
to fix.


Shim6 is an answer to "what kind of multihoming can we offer to sites 
without PI space?"; it is yet to be seen if anyone cares about the answer to 
that question.


The question that folks with money are asking is "how do I ensure that any 
random user can get reliable access to my website", and that's a question 
that the IETF is, in general, uninterested in.


However, it's not hard to find examples in today's v4 Internet where 
reconvergence following a re-homing event can take 30 to 60 seconds  to 
occur. In the case where such an event includes some interface  flapping, 
it's not that uncommon to see paths suppressed due to  dampening for 20-30 
minutes.


That may be acceptable compared to the general limitations of PA space. 
Folks have learned to deal with the limitations of BGP-based redundancy; 
asking them to give those benefits up without substantially greater benefits 
is foolhardy.


I would expect (in some future, hypothetical implementation of shim6) 
that the default failure detection timers to start rotating through  the 
locator set far sooner than 30-60 seconds.


If we ever see shim6 (or its equivalent) widely deployed...  So far, we 
don't even have simple IPv6 on even a noticeable fraction of end nodes.


Any solution which requires upgrading all the end nodes is a non-starter, 
and the IETF needs to wake up to that fact.  It's taken over a _decade_ for 
simple IPv6 to make it into host stacks, and it's still not viable yet.  No 
host-dependent upgrade will matter to the Internet over the long run.



No; maintain one address per PA netblock on each host.


And so, if I have 6 upstream providers, every one of my hosts has to keep 
track of the outbound policy I want for each?  How exactly am I supposed to 
keep track of that?  Even the outbound policy for a single host (aka 
firewall) is beyond most organizations' capabilities today...


Why is it even remotely rational that a corporate admin trust 100k+ hosts 
infested with worms, virii, spam, malware, etc. to handle multihoming 
decisions?  Especially when we don't even have a sample of working code 
today?  I don't even trust the <5 PCs I have at home to make those kind of 
decisions, much less every PC in my corporate network...


There's a vast difference in impact on the state held in the core  between 
deaggregating towards direct peers, and deaggregating towards  transit 
providers and having the deaggregated swamp propagated globally.


Obviously, folks differ in their definition of "swamp".

I'd love a world where $large orgs could connect to N providers and not have 
to figure out the vagaries of BGP, but the reality is that if a large 
customer depends on the Internet for their financial health connectivity, 
the only answer today (with either v4 or v6) is PI space.


Now, some may take that as a sign the IETF needs to figure out how to handle 
10^6 BGP prefixes...  I'm not sure we'll be there for a few years with IPv6, 
but sooner or later we will, and someone needs to figure out what the 
Internet is going to look like at that point.  If the IETF isn't interested, 
some group of vendors will, if for no other reason than that's what will be 
needed for the vendors to sell routers in a few years.  Is it any surprise 
that $vendor is pushing how many millions of routes they can handle in the 
FIB today?


IPv6 is just a convenient placeholder for all the problems that today's ISPs 
are ignoring about today's Internet.


S

Stephen Sprunk"Stupid people surround themselves with smart
CCIE #3723   people.  Smart people surround themselves with
K5SSS smart people who disagree with them."  --Aaron Sorkin 

Re: Shim6 vs PI addressing

[Jeroen Massar]

[Pekka, thanks for the Shim6 Summary paper ;) ]

On Wed, 2006-03-01 at 14:58 -0800, Owen DeLong wrote:
> > Please don't mix up addressing and routing. "PI addressing" as you
> > mention is addressing. SHIM6 will become a routing trick.
> > 
> I think that is overly pessimistic.  I would say that SHIM6 _MAY_
> become a routing trick, but, so far, SHIM6 is a still-born piece
> of overly complicated vaporware of minimal operational value, if any.

Vaporware part is true, upto now, operational value is to be seen.

> Personally, I think a better solution is to stop overloading IDR
> meaning onto IP addresses and use ASNs for IDR and prefixes for
> intradomain routing only.

Did you notice that 32bit ASN's are coming and that IPv4 addresses are
32bits? :) Which effectively means that we are going to route IPv6 with
an IPv4 address space. Or when one would use the 32bit ASN for IPv4:
routing a 32bit address space with an 32bit routing ID. The mere
difference

> > Greets,
> >  Jeroen
> > 
> > (who simply would like a policy where endsites that want it could
> > request a /48 or /40 depending on requirements from a dedicated block
> > which one day might be used for identity purposes and not pop up in the
> > bgp tables or whatever we have then anymore)
> > 
> I would, for one.  Policy proposal 2005-1 (I am the author) comes reasonably
> close to that.  It will be discussed at the ARIN policy meeting in
> Montreal in April.

Yep, 2005-1 fits my idea pretty well. Takes care of the folks needing
address space now while being able to use it differently later when it
is needed.

Though as Joe Abley also mentioned (and I also quite a number of times
already ;) anyone with even a vague definition of a plan for 200
customers can get a /32 IPv6 without a problem. Just check the GRH list
for companies in your neighbourhood who did get it.

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part

Re: Shim6 vs PI addressing

[Owen DeLong]

I think that is overly pessimistic.  I would say that SHIM6 _MAY_
become a routing trick, but, so far, SHIM6 is a still-born piece
of overly complicated vaporware of minimal operational value, if any.


Vaporware part is true, upto now, operational value is to be seen.


Well... I can only go based on the existing drafts since there's no
running code to base an opinion on, but, my opinion of the drafts
is that it will provide minimal operational value.

It's the wrong answer to the wrong question, in my opinion.


Personally, I think a better solution is to stop overloading IDR
meaning onto IP addresses and use ASNs for IDR and prefixes for
intradomain routing only.


Did you notice that 32bit ASN's are coming and that IPv4 addresses are
32bits? :) Which effectively means that we are going to route IPv6 with
an IPv4 address space. Or when one would use the 32bit ASN for IPv4:
routing a 32bit address space with an 32bit routing ID. The mere
difference


Yes, I am well aware of 32bit ASNs.  However, some things to consider:

1.  Just because ASNs are 32 bits doesn't mean we'll instantly
issue all 4 billion of them.  The reality is that we probably
only need about 18 bits to express all the ASNs well need for
the life of IPv6, but, 32 is the next convenient size and there's
really no benefit to going with less than 32.

2.  In my current thinking on how to achieve ASN based IDR, we
would not need ASNs for every organization that multihomes,
only for each organization that provides transit.  This
would greatly reduce some of the current and future demand
for ASNs.


Yep, 2005-1 fits my idea pretty well. Takes care of the folks needing
address space now while being able to use it differently later when it
is needed.

Though as Joe Abley also mentioned (and I also quite a number of times
already ;) anyone with even a vague definition of a plan for 200
customers can get a /32 IPv6 without a problem. Just check the GRH list
for companies in your neighbourhood who did get it.


True, but, until recently, I was being told that ARIN insisted that the
200 "customers" had to be non-related third parties.  E.g. Chevron
couldn't use all their different business units as 200 customers of
Chevron Corporate IT.  It appears based on some recent allocations that
they may have relaxed that stance.

Regards,

Owen





pgpJQC40MCVGM.pgp
Description: PGP signature

Re: Shim6 vs PI addressing

[Jeroen Massar]

On Thu, 2006-03-02 at 02:21 -0800, Owen DeLong wrote:
> >> Personally, I think a better solution is to stop overloading IDR
> >> meaning onto IP addresses and use ASNs for IDR and prefixes for
> >> intradomain routing only.
> >
> > Did you notice that 32bit ASN's are coming and that IPv4 addresses are
> > 32bits? :) Which effectively means that we are going to route IPv6 with
> > an IPv4 address space. Or when one would use the 32bit ASN for IPv4:
> > routing a 32bit address space with an 32bit routing ID. The mere
> > difference
> >
> Yes, I am well aware of 32bit ASNs.  However, some things to consider:
> 
> 1.Just because ASNs are 32 bits doesn't mean we'll instantly
>   issue all 4 billion of them.  The reality is that we probably
>   only need about 18 bits to express all the ASNs well need for
>   the life of IPv6, but, 32 is the next convenient size and there's
>   really no benefit to going with less than 32.

True. If we would take the 170k routes that are in BGP at the moment
then a 18bits address space is enough to give every route a dedicated
ASN. The issue is that there are way more people who might want to
multihome than that, just take the number of businesses on this planet,
add some future growth and we'll end up using the 24th bit too quite
quickly. Which is, according to some people who do routing code, no
problem at all. Like shim6, see first then believe.

> 2.In my current thinking on how to achieve ASN based IDR, we
>   would not need ASNs for every organization that multihomes,
>   only for each organization that provides transit.  This
>   would greatly reduce some of the current and future demand
>   for ASNs.

Paper/draft/description/website? :)

> > Yep, 2005-1 fits my idea pretty well. Takes care of the folks needing
> > address space now while being able to use it differently later when it
> > is needed.
> >
> > Though as Joe Abley also mentioned (and I also quite a number of times
> > already ;) anyone with even a vague definition of a plan for 200
> > customers can get a /32 IPv6 without a problem. Just check the GRH list
> > for companies in your neighbourhood who did get it.
> >
> True, but, until recently, I was being told that ARIN insisted that the
> 200 "customers" had to be non-related third parties.  E.g. Chevron
> couldn't use all their different business units as 200 customers of
> Chevron Corporate IT.  It appears based on some recent allocations that
> they may have relaxed that stance.

It might have been that ARIN was a bit stricter, the other RIR's though
have never given any real problems as far as I know. The few ones that I
heared of that couldn't get it, either didn't try or didn't want to
"lie" about their plans.

Greets,
 Jeroen



signature.asc
Description: This is a digitally signed message part

Re: Quarantine your infected users spreading malware

[Jim Segrave]

On Tue 28 Feb 2006 (19:29 +), Christopher L. Morrow wrote:
> 
> 
> On Tue, 28 Feb 2006, Bill Nash wrote:
> 
> >
> > The simplest method is to issue a different gateway to a registry of known
> > offenders, forcing their into a restrictive environment that blocks all
> > ports, and uses network translation tricks to redirect all web traffic to
> > a portal.
> >
> > For cable modems and bridged DSL, you can do this with DHCP, matching
> > their MAC address. PPPOE/DSL or similiar, you match on user name.
> > Issue RFC1918 space with a gateway to your quarantine network.
> >
> > The rest is NAT/PAT and w3proxy stunts. You could pull it off with
> > something as simple as iptables and squid, after dealing with the DHCP or
> > authentication servers (ala Radius) to issue to the correct credentials.
> >
> 
> yes, I could dream up a few hundred ways to accomplish this, but the
> 'documentation' at the site referenced doesn't address even one way. So,
> saying 'it works' and 'it works for carriers' and 'yea us!' is not
> helpful, without some example of 'how' :(

You did think of contacting them and asking? You know, e-mail, fax,
telephone, that sort of thing?

The first time I mentioned this company, I said that it is used to put
infected customers into a virtual router where all their internet
traffic is proxied via a server. which blocks unwanted addresses,
answers web requests not to designated servers from an internal
service - so going to google.com brings up the page explaining why
your account is quarantined.

The specifics of connecting it to your network, oddly enough, probably
will depend on how your network is built, which is why you might need
to contact them.

I thought this was a network operator's mailing list, not a
spoon-feeding session

-- 
Jim Segrave   [EMAIL PROTECTED]

Re: Shim6 vs PI addressing

[Mark Newton]

On Thu, Mar 02, 2006 at 02:21:45AM -0800, Owen DeLong wrote:

 > Yes, I am well aware of 32bit ASNs.  However, some things to consider:
 > 1.   Just because ASNs are 32 bits doesn't mean we'll instantly
 >  issue all 4 billion of them.  The reality is that we probably
 >  only need about 18 bits to express all the ASNs well need for
 >  the life of IPv6, but, 32 is the next convenient size and there's
 >  really no benefit to going with less than 32.

It's probably worth using this juncture to point out that exactly
the same principle applies to the bit-width gap between IPv4 and IPv6:
the fact that IPv6 gives 128 bits doesn't mean we're going to allocate
all of them right away.

The number of networks in use is not driven by the size of the 
address space;  it's driven by the number of enterprises who wish
to connect to the Internet, the number of sites at which they wish
to connect, the number of interfaces they wish to use to carry
out their interconnections, and the number of hosts they're bringing
along with each connection.

Notice that none of that has anything to do with the version number
of the protocol which those hosts are speaking.  By any way you 
measure it, Internet growth is a function of end-user demand, not
a function of the number of bits in an IP address.

We can spend another decade talking about how to manage routing
table growth if we really want to, but during that decade the
routing table is going to *keep growing anyway*.  If we want to
prevent it from growing, the only real way to do it is going to
be at the demand side -- which is another way of saying that we'd
need to address and control all of the clauses I iterated through
two paragraphs ago. 

When you distill *that* message to its essence, you can restate it
like this:

  "We can control the growth of the IP routing table by making 
  it harder for people to connect their networks to the Internet."

Because that's what the advocates for IPv6 universal PA space 
are *really* saying, once you remove all the smoke and mirrors.

... which neatly explains a major reason for why IPv6 hasn't taken
off, and why shim6 remains vapourware despite many years of discussion
and the presence of a clear, unambiguous demand for a solution
to the multihoming problem.

What's the way out?  Acknowledgement of the fact that the size
of the routing table is a function of the size of the Internet.
Y'know, one of those "duh!" statements.  If we expect the Internet
to grow past 32-bit limitations, we're going to have to expect
the routing table to grow past the constraints which that 32-bit
world has imposed upon it.  Solving *that* problem is, IMHO,
overwhelmingly preferable to breaking multihoming and handing
routing policy decisions over to the viruses and worms which
control each host.

(note that I'm not pretending that solving the routing table
growth problem is -easy-, it's just plainly obvious to me that
it'll need to be solved anyway, and the IPv6 PA advocacy that
keeps coming up seems to be an exercise in denial...)

  - mark


-- 
Mark Newton   Email:  [EMAIL PROTECTED] (W)
Network Engineer  Email:  [EMAIL PROTECTED]  (H)
Internode Systems Pty Ltd Desk:   +61-8-82282999
"Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223

Re: Quarantine your infected users spreading malware

[Jim Segrave]

On Wed 01 Mar 2006 (16:33 +), Christopher L. Morrow wrote:
> 
> 
> On Wed, 1 Mar 2006, JP Velders wrote:
> 
> >
> > > Date: Tue, 28 Feb 2006 18:50:29 + (GMT)
> > > From: Christopher L. Morrow <[EMAIL PROTECTED]>
> > > To: nanog@merit.edu
> > > Subject: Re: Quarantine your infected users spreading malware
> >
> > > On Tue, 28 Feb 2006, Jim Segrave wrote:
> >
> > > > www.quarantainenet.nl
> >
> > > > It puts them in a protected environment where they can get cleaned up
> > > > on-line without serious risk of re-infection. They can pop their
> > > > e-mail, reply via webmail, but they can't connect to anywhere except a
> > > > list of update sites.
> >
> > > there was little in the way of 'how' in the link above though :(
> >
> > Well, it's very much dependant on your own network.
> > >From what I know (from presentations of the folk behind Qnet, and
> > talks with people actually using it) is that they have a sort of
> > "export" module, which allows you to either output the IP's, or parse
> > them such that you get a crafted DHCP entry, or special MAC address
> > based "alternate VLAN" statement for on a switch etc.
> 
> which is fabulous for those of you with ethernet... without ethernet most
> of these solutions fall on their faces and die the horrid death of an
> enterprise product :( Now, they say: "Works great on carrier networks"...
> my question was "how" and "perhaps with a little less hand-waviness
> please?"

You could have answered your own questions, for your own network, in
the same amount of time as writing these postings to nanog, by asking
the company.

-- 
Jim Segrave   [EMAIL PROTECTED]

Re: Quarantine your infected users spreading malware

[Jim Segrave]

On Wed 01 Mar 2006 (11:42 -0600), Jack Bates wrote:
> 
> Christopher L. Morrow wrote:
> 
> >agreed, punting this problem to the helpdesk makes the helpdesk manager
> >grab his gun(s) and find the security wonk that put a hurtin' on his
> >numbers :) Also, it costs lots of money, which isn't generally a good
> >plan.
> 
> Do you find that web redirection actually stems the flow of calls to the 
> helpdesk? We find that anything out of the normal usually results in a 
> customer calling the helpdesk just because they weren't expecting it. We 
> found this to be true of email notifications as well. The other issue 
> is, of course, differing what we are doing with those thousands of 
> annoying ads that make users believe they are infected.

Yes, it reduces, but does not stop the number of calls. More
importantly, because the customer can still access sites such as MS
update, Norton, McAfee, Housecall etc, even while quarantined, those
people who call the helpdesk can get directed to the "how to fix it
page" rapidly, so the calls stay shorter.

-- 
Jim Segrave   [EMAIL PROTECTED]

Re: the need for shim6

[Edward B. DREGER]

Sorry to respond to my own post.  I omitted a key point:

Note that a calling card doesn't even really approximate source routing.  
It's more of an anycasted proxy.


Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita

DO NOT send mail to the following addresses:
[EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.

Notes on design of IPv6 BGP multihoming with special subroute attributes (was - Re: Shim6 vs PI addressing)

[william(at)elan.net]

On Thu, 2 Mar 2006, Owen DeLong wrote:


I think that is overly pessimistic.  I would say that SHIM6 _MAY_



Yes, I am well aware of 32bit ASNs.  However, some things to consider:

1.  Just because ASNs are 32 bits doesn't mean we'll instantly
issue all 4 billion of them.  The reality is that we probably
only need about 18 bits to express all the ASNs well need for


Probably 20 bits or 24 bits rather then 18. It maybe worth it to reserve 
top 8 bits for some experimental future use.



the life of IPv6, but, 32 is the next convenient size and there's
really no benefit to going with less than 32.

2.  In my current thinking on how to achieve ASN based IDR, we
would not need ASNs for every organization that multihomes,
only for each organization that provides transit.  This
would greatly reduce some of the current and future demand
for ASNs.


I thought of something of this sort some time ago but never got around
to full proposal on it (maybe somebody else did?). I'm trying to go
through my notes now - maybe it could prove useful if research or
engineering people do indeed want to work on something like that.

My thinking was that its a big waste of memory (in the global bgp table) 
to announce every IPv6 route in full in particular for cases when its 
sub-allocation and aggregate is already being announced. As an example 
lets take some ip block like say A100:1000::/32 that is allocated to an 
ISP 'A' by RIR. Now lets say that this ISP 'A' (AS1) has a customer who 
received A100:1000:0010::/48 and later same customer got connection from 
ISP 'B' (AS2) as well and wants to multihome. For normal BGP that would 
mean that full route of A100:1000:0010::/48 would appear in BGP and 
increase its size quite a bit.


But it maybe possible to do limited bgp multi-homing by having such /48 
and similar routes included as attributes of the main route, i.e.

 A100:1000::/32 route would appear with extended attributes like
   Subroutes: 0010/16 (2)

Where "0010/16" indicates subroute as seen within A100:1000::/32 ip block 
(i.e. netmask here is added to netmask of A100:1000 route to get full 
netmask on the internet) and "(2)" is an additional ASN that such subroute 
can also be found through. Now if properly designed, such subroute 
attribute can be compacted to be around 64 bits extra each (slightly
more if multihoming is through more then one ASN and subblock is smaller 
size then /16) and 64bits data for each multi-homed customer in BGP appear 
to me something that we can deal with.


Unfortunately with this design, the issue then becomes how some AS10
(the end-site) knows how to get to AS2 (one way maybe to do ASN routes 
as part of BGP in addition to ipv4 and ipv6 routes). As well as what to
do if connection from customer to AS1 or from AS1 to internet drops 
since its AS1 that announces such subroutes as part of its aggregate

and purpose of multi-homing it to let it work without it (this can be
done with AS2 also announcing A100:1000::/32 but with special attribute
indicating its valid only for subroutes and such route should not be
propagated if same ASN also sees primary AS1 direct route).

Another possibility of similar design (kind-of already mentioned above)
is to allow AS2 to announce A100:1000::/32 on the internet as it would
its own route but indicate that it is valid only for specific subroutes 
and not as an aggregate (in fact in this design AS1 would not even have 
subroutes in its main route announcement). While this means entire full 
route on the net, the hope is that if AS1 and AS2 have number of common 
multi-homed customers, the net would be spared from separate BGP routes 
for each one and the end-site AS10 would only see something like:

 BGP routing table for A1000:1000::/32
   9 8 7 6 1
 Origin IGP
   5 4 3 2
 Origin IGP, Subroutes-Only
 Subroutes: 0010/16 0101/16
So from above if router needs to send data to either A1000:1000:0010::/48
or A100:1000:0101::/48 it would choose 2nd path through peer AS5 as 
having smaller as-path.


All these approaches (especially second one) however certain problems when
you have to consider route security & authorization (i.e. SIDR/SBGP space)
as its necessary to convey that AS2 is to be allowed to announce A100:1000:
block for specific subroutes. But I think these issues can be worked out
like having AS2 sendscertificate request for subblock to AS1 which it then
signs and gives new certificate authorizing announcement with specific
subblock attribute to AS2.

More general issues with these approaches is obviously that there is no
possibility of PI space as customers that need multi-homing would have to 
get space from one of its ISPs (well, actually it is still possible to do 
PI - it is just that multiple ISPs would be expected to announce large

aggregate of the PI block with bunch of subroutes on equal basis).

Anyway, if you have comments or if something like this h

Re: shim6 @ NANOG (forwarded note from John Payne)

[David Barak]

--- [EMAIL PROTECTED] wrote:

> > Resounding YES - I specifically DON'T want
> end-hosts
> > to be able to make these decisions, but need to be
> > able to multihome.
> 
> When I see comments like this I wonder whether
> people
> understand what shim6 is all about. First of all,
> these
> aren't YOUR hosts. They belong to somebody else. If
> you
> are an access provider then these hosts belong to a
> customer
> that is paying you to carry packets. This customer
> also
> pays another ISP for the same service and the hosts
> are making decisions about whether to use your
> service
> or your competitors. 
> 
> If you are a hosting provider, then these hosts,
> owned 
> by a third party, are making decisions about whether
> to
> send you packets through one or another AS.
> 
> Is there something inherently wrong with independent
> organizations deciding where to send their packets?

That's not the case I'm discussing - I'm talking about
the multihomed enterprise.  From an access provider
point of view, Shim6 is no worse/better than the
various TE-fu devices which end customers use - it
makes predicting load a bit more difficult, but it's
just bits to be passed.  From an enterprise POV I want
two or three decision points which I need to monitor
and manage, not 10,000.

> P.S. I don't believe that shim6 will ever succeed.

Neither do I.



David Barak
Need Geek Rock?  Try The Franchise: 
http://www.listentothefranchise.com

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: shim6 @ NANOG (forwarded note from John Payne)

[Edward B. DREGER]

Date: Thu, 2 Mar 2006 10:07:33 +
From: [EMAIL PROTECTED]


[ snip ]


Is there something inherently wrong with independent
organizations deciding where to send their packets?


1. Many a transit seems to think so.
2. Is there an inherent need?
3. Is this DPA+sourceroute cocktail the best method?


Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita

DO NOT send mail to the following addresses:
[EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.

Re: Quarantine your infected users spreading malware

[Robert E . Seastrom]

Jim Segrave <[EMAIL PROTECTED]> writes:

>> On Tue, 28 Feb 2006, Bill Nash wrote:
>>
>> > The simplest method is to issue a different gateway to a registry of known
>> > offenders, forcing their into a restrictive environment that blocks all
>> > ports, and uses network translation tricks to redirect all web traffic to
>> > a portal.
>
> You did think of contacting them and asking? You know, e-mail, fax,
> telephone, that sort of thing?

Yes, we did think of that sort of thing.  Those of us with even the
slightest notion of business and profitability constraints promptly
discarded the idea of getting a human into the loop.  Ideally you just
automatically add them to the broken stuff database, notify/incent
them to fix things (by adding them to the quarantine group), and have
them take care of themselves by following the directions found
therein, and NOT involving your call center.

---Rob

Re: Quarantine your infected users spreading malware

[Niels Raijer]

On Thu, Mar 02, 2006 at 07:57:14AM -0500, Robert E. Seastrom wrote:

> Jim Segrave <[EMAIL PROTECTED]> writes:
> 
> > You did think of contacting them and asking? You know, e-mail, fax,
> > telephone, that sort of thing?
> 
> Yes, we did think of that sort of thing.  Those of us with even the
> slightest notion of business and profitability constraints promptly
> discarded the idea of getting a human into the loop.  Ideally you just

I think what Jim meant was something else: that if you have questions
about the Quarantainenet product, you contact the Quarantainenet people
via e-mail, fax or telephone and ask. 'Them' was not referring to actual
customers this time.
-- 
Niels Raijer   |  "But in the pocket of my clothes
[EMAIL PROTECTED] |   was a single white rose
http://www.fusix.nl|  for Pierrette..."

Re: Notes on design of IPv6 BGP multihoming with special subroute attributes (was - Re: Shim6 vs PI addressing)

[Iljitsch van Beijnum]

On 2-mrt-2006, at 13:44, william(at)elan.net wrote:


2.  In my current thinking on how to achieve ASN based IDR, we
would not need ASNs for every organization that multihomes,
only for each organization that provides transit.  This
would greatly reduce some of the current and future demand
for ASNs.


Yes, we wouldn't want to run out of AS numbers just now we're  
creating 4.29 billion new ones...


My thinking was that its a big waste of memory (in the global bgp  
table) to announce every IPv6 route in full in particular for cases  
when its sub-allocation and aggregate is already being announced.


Yes, it would be cool if the routers or route servers could  
automatically detect this and clean up the routing table. Unfortunately:


A --- B
  / \
X Y
  \ /
C --- D

If X uses 172.16.1.0/24 but A also announces 172.16.0.0/12, then A or  
B could decide to suppress the /24. However, Y will see the /24  
through D and C but not through B and A, so Y will now send all of  
its traffic to X through C and D.


But it maybe possible to do limited bgp multi-homing by having  
such /48 and similar routes included as attributes of the main  
route, i.e.

 A100:1000::/32 route would appear with extended attributes like
   Subroutes: 0010/16 (2)


Some years ago, I suggested doing this by adding a bitmap to the  
aggregate route: a single bit is enough to convey holes in the  
aggregate, with two or three bits you can also do some traffic  
engineering. This will get you from a /16 aggregate to individual / 
24s with 32 bytes (1 bit per more specific) or a /32 to /48s with 8  
kilobytes.


Such an approach does depend on relatively tight packing of end-users  
that share the same ISPs, though.


All these approaches (especially second one) however certain  
problems when
you have to consider route security & authorization (i.e. SIDR/SBGP  
space)


IDR security doesn't come cheap anyway: be prepared to double or  
quadruple your router's memory and install crypto hardware.

Re: shim6 @ NANOG (forwarded note from John Payne)

[Kevin Day]

On Mar 2, 2006, at 4:07 AM, [EMAIL PROTECTED] wrote:

ome.


When I see comments like this I wonder whether people
understand what shim6 is all about. First of all, these
aren't YOUR hosts. They belong to somebody else. If you
are an access provider then these hosts belong to a customer
that is paying you to carry packets. This customer also
pays another ISP for the same service and the hosts
are making decisions about whether to use your service
or your competitors.

If you are a hosting provider, then these hosts, owned
by a third party, are making decisions about whether to
send you packets through one or another AS.

Is there something inherently wrong with independent
organizations deciding where to send their packets?


The problem is when the *hosting company* or *ISP* is multihomed and  
using shim6. The customers aren't straddling two hosting companies,  
they're using a hosting company who is using shim6.


Take us as a slightly exaggerated example(using totally made up  
bandwidth and prices, to protect NDAs). We have several boxes on our  
network that we do not control, we don't even have a login on the  
server.


In one POP we have three transit providers. NSP A gives us 10Gbps of  
bandwidth, and charges us $50/mbps. NSP B is on a GigE, but we only  
have a 500mbps commit. B charges us $75/mbps, but $150/mbps if we go  
over our commit. NSP C is also on a GigE, but we only have a 100mbps  
commit, charges us $200/mbps, and $500/mbps if we go over our commit.


I don't want a customer to touch NSP C, except for a very tiny number  
of routes where A and B aren't so great. I want to use NSP B as close  
to, but not going over, our commit as possible. I want everything  
else to go over NSP A. If any of the three transit connections go  
down, all the rules change temporarily (but hopefully not for long  
enough that we get dinged for 95th-percentile)


Putting the routing decisions in the hands of the servers(that we do  
not control) requires that we somehow impart this routing policy on  
our customers, make them keep it up to date when we change things,  
and somehow enforce that they don't break the policy.  If a customer  
sees that forcing traffic to go through NSP C results in a faster  
connection for him, they may tweak/break the selection process of  
shim6(or just ignore our policy instructions) and cost us lots of  
money. We may learn from one of our providers that they lost an OC48  
in our city, and can't handle our full traffic so we need to back off  
immediately. Or we can know in advance that a connection is about to  
go down, and want to preemptively route around it before things get  
blackholed before the routers notice.


On very high traffic days, we may make 10+ manual changes to our BGP  
policies to balance outbound and inbound traffic, to keep levels  
under their commits while still utilizing as much of our commit as  
possible. We have automated tools that make slight tweaks every 5  
minutes. How can information that changes this frequently, and  
involves a very large dataset (several full tables of routes) get  
propagated to hundreds/thousands of hosts in a reasonable timeframe?  
Are we reinventing BGP as an IGP to send route data to shim6? :) And  
do we want to blow that much ram keeping a full routing table on each  
server? Even compressed to only list exceptions to a default route,  
my list of exceptions is still huge.



The same problems exist, on a smaller level, on enterprise networks.  
Routing policies can be complex, requiring information that isn't  
currently visible to end hosts, that changes frequently, and can be  
very costly if anyone ignores the policy. Under current BGP-style  
decisions-at-the-edges networking, it's impossible for an end user or  
server to ignore routing policy. With shim6, the end nodes ARE the  
routing policy. There's a lot more to many network's decision making  
process of "how to select the best route" that can't be measured with  
RTT or received TTLs, or anything else the end nodes can see.



Even outside the case of enterprise/hosting environments, transit  
providers already send route preference data to their customers. As a  
transit provider I'm able to depref/prepend/tag/etc routes to  
customers that we'd rather they not use (but are free to ignore).  
Under shim6, it's not really possible for your upstreams to tell you  
"My connection to this network is degraded at the moment, use it only  
as a last resort", where as with BGP they can prepend those routes a  
dozen times or flag it with a community and you won't use it unless  
you have to. Under host-based routing, all end nodes have to be made  
aware of this information.


Something like shim6 works great for small or medium businesses where  
they don't care about this sort of thing, their routing policies only  
change when they add/drop a provider, and they don't have thousands  
of customers with root access on their boxes trying to game 

Important Statement to Review for Signing

[Seth Johnson]

(Apologies for the political/non-strictly-technical substance of
this post; but I think this group is populated by the right
people who would understand the issue, sign the statement, and
know who all else should be approached.  -- Seth Johnson)

Hello folks,

Please review the important joint statement below, related to the
WIPO Broadcaster's Treaty, and consider adding your signature if
you are an American citizen.  Also make sure those you know who
should sign are also given the opportunity.

Andy Oram has written a good letter to the US Delegation to WIPO
on the subject:
> http://www.oreillynet.com/pub/a/etel/2006/01/13/the-problem-with-webcasting.html?page=2

CPTech Links on the Treaty:
> http://www.cptech.org/ip/wipo/bt/index.html#Coments
Electronic Frontier Foundation Links:
> http://www.eff.org/IP/WIPO/broadcasting_treaty/
IP Justice Links:
> http://www.ipjustice.org/WIPO/broadcasters.shtml
Union for the Public Domain Links:
> http://www.public-domain.org/?q=node/47

The Latest Draft of the Treaty:
> http://www.cptech.org/ip/wipo/sccr12.2rev2.doc

A survey of relevant links:
> http://www.hyperorg.com/blogger/mtarchive/wipo_and_the_war_against_the_i.html

If you choose to sign, please send your name along with an
affiliation or appropriate short phrase to attach to your name
for identification purposes, to mailto:[EMAIL PROTECTED] 
If your organization endorses the statement, please indicate that
separately, so your organization will be listed under that
header.

Thank you for consideration.


Seth Johnson
Corresponding Secretary
New Yorkers for Fair Use


Joint Statement to Congress:


Dear (Relevant Congressional Committees) (cc the WIPO
Delegation):

Negotiations are currently underway at the World Intellectual
Property Organization (WIPO) to develop a treaty giving
broadcasters power to suppress currently lawful communications.
The United States delegation is also advocating similar rights
for "webcasters" through which the authors of new works
communicate them to the public.

Some provisions of the proposed "Treaty on the Protection of
Broadcasting Organizations" would merely update and standardize
existing legal norms, but several proposals would require
Congress to enact sweeping new laws that give private parties
control over information, communication, and even copyrighted
works of others, whenever they have broadcast or "webcast" the
work.

The novel policy areas addressed by this treaty go beyond
ordinary treaty-making that seeks worldwide adherence to U.S.
policy. Instead, this initiative invades Congress’ prerogative to
develop and establish national policy.  Indeed, even as Congress
is debating how best to protect network neutrality, treaty
negotiators are debating how to eliminate it.

The threat to personal liberties presented by this treaty is too
grave to allow these new policy initiatives be handed over to an
unelected delegation to negotiate with foreign countries, leaving
Congress with the sole option whether to acquiesce.  When dealing
with policies that are related to copyright and communications,
Congress's assigned powers and responsibility under Article I,
Section 8 of the Constitution become particularly important.  We
urge two important steps.  First, the new proposed regulations
should be published in the Federal Register, with an invitation
to the public to comment. Second, the appropriate House and
Senate committees should hold hearings to more fully explore the
impact of these novel legal restrictions on commerce, freedom of
speech, copyright holders, network neutrality, and communications
policy.

Americans currently enjoy substantial freedoms with respect to
broadcast and webcast communications.  Under the proposed treaty,
the existing options available to commercial enterprises and
entrepreneurs as well as the general public to communicate news,
information and entertainment would be limited by a new private
gatekeeper who adds nothing of value to the content.
Communications policies currently under discussion at the FCC
would be impacted.  Individuals and small businesses would be
limited in their freedom of speech.  Copyright owners would find
their freedom to license their works limited by whether the work
had been broadcast or webcast.  The principle of network
neutrality, already the subject of congressional hearings, would
be all but destroyed.

As able as the staff of the United States Patent and Trademark
Office and the Library of Congress may be, it was never intended
that they alone should stake out the United States national
policy to be promoted before an unelected international body in
entirely new areas abridging civil liberties. Congress should be
the first to establish America’s national policies in this new
area so that our WIPO delegation will have sufficient guidance to
achieve legitimate objectives without impairing Constitutional
principles such as freedom of speech and assembly, without
impairing the value of copyrights, and without granting

Re: shim6 @ NANOG (forwarded note from John Payne)

[Michael . Dillon]

> Putting the routing decisions in the hands of the servers(that we do 
> not control) requires that we somehow impart this routing policy on 
> our customers, make them keep it up to date when we change things, 
> and somehow enforce that they don't break the policy.

> The same problems exist, on a smaller level, on enterprise networks. 
> Routing policies can be complex, requiring information that isn't 
> currently visible to end hosts, that changes frequently, and can be 
> very costly if anyone ignores the policy. Under current BGP-style 
> decisions-at-the-edges networking, it's impossible for an end user or 
> server to ignore routing policy. 

Clearly, it would be extremely unwise for an ISP or
an enterprise to rely on shim6 for multihoming. Fortunately
they won't have to do this because the BGP multihoming
option will be available.

> I just don't think it's a solution for everyone.

It may never be a solution for anyone.

--Michael Dillon

Re: shim6 @ NANOG (forwarded note from John Payne)

[Iljitsch van Beijnum]

On 2-mrt-2006, at 14:49, [EMAIL PROTECTED] wrote:


Clearly, it would be extremely unwise for an ISP or
an enterprise to rely on shim6 for multihoming. Fortunately
they won't have to do this because the BGP multihoming
option will be available.


I guess you have a better crystal ball than I do.

One thing is very certain: today, a lot of people who have their own  
PI or even PA block with IPv4, don't qualify for one with IPv6. While  
it's certainly possible that the rules will be changed such that more  
people can get an IPv6 PI or PA block, it is EXTREMELY unlikely that  
this will become as easy as with IPv4.


Ergo: some people who multihome with BGP in IPv4 today won't be able  
to do the same with IPv6. And if you manage to get a PI or PA block  
you will very likely find that deaggregating won't work nearly as  
well with IPv6 as it does with IPv4.


So learn to love shim6 or help create something better. Complaining  
isn't going to solve anything.

Re: shim6 @ NANOG (forwarded note from John Payne)

[Kevin Day]

On Mar 2, 2006, at 7:49 AM, [EMAIL PROTECTED] wrote:




Clearly, it would be extremely unwise for an ISP or
an enterprise to rely on shim6 for multihoming. Fortunately
they won't have to do this because the BGP multihoming
option will be available.



Are you *sure* BGP multihoming will be available? This is my  
interpretation of the IPv6 /32 allocation policy:


To receive an allocation of a /32, you must:

"A) Be an LIR". I think you can consider a hosting company an LIR.

"B) Not be an end site". A little less cut and dry, but I'll accept  
that a hosting company doesn't fit the definition of an end site.


"C) plan to provide IPv6 connectivity to organizations to which it  
will assign /48s, by advertising that connectivity through its single  
aggregated address allocation". This is the one where I don't think a  
hosting company fits.


If all of your hosting is "shared", the servers are your  
responsibility, and you're not providing connectivity to anyone but  
yourself. I don't think you qualify at all at this point.


If you're selling dedicated servers or colo space, it's a little  
better, but I still don't think you fit. The average dedicated  
hosting/colo company now runs many customers servers sharing one  
subnet. Each customer gets /32's assigned per server, unless you're a  
huge colo customer, you're not getting space SWIPed to you.


When deciding who gets space out of your /32:

Assignments are to be made in accordance with the existing  
guidelines (RFC3177,RIRs-on-48), which are summarized here as:


- /48 in the general case, except for very large subscribers

- /64 when it is known that one and only one subnet is needed by  
design


- /128 when it is absolutely known that one and only one device is  
connecting.


One customer on one dedicated server gets a /128. Even if you stretch  
plausibility, they only get a /64. I don't see any way you can  
justify giving colo customers /48s, unless they're deploying huge  
networks in your datacenter.


The final rule for getting a /32 is:

"D) be an existing, known ISP in the ARIN region or have a plan for  
making at least 200 /48 assignments to other organizations within  
five years."


Unless you're providing transit/connectivity to 200 companies/ 
networks, I can't see how you justify assigning even ONE /48, let  
alone 200.




The other PI assignment policies that have been proposed either  
require that you have a /19 already in IPv4 (lots of hosting  
companies don't have anything this size), or have tens/hundreds of  
thousands of devices.


Even if a hosting company does get a /32 or a /44 or whatever, the  
"you can't deaggregate your assignment at all" policy rules out  
having multiple independent POPs unless you somehow arrange to get  
multiple allocations(which isn't possible now).

Re: Shim6 vs PI addressing

[Jared Mauch]

On Wed, Mar 01, 2006 at 03:01:22PM -0800, Owen DeLong wrote:
> > I think you're missing that some people do odd
> > things with their IPs as well, like have one ASN and 35
> > different sites where they connect to their upstream Tier69.net
> > all with the same ASN.  This means that their 35 offices/sites
> > will each need a /32, not one per the entire asn in the table.
> > 
> People who are doing that have not read the definition of the
> term ASN and there is no reason that the community or public
> policy should concern itself with supporting such violations
> of the RFCs.  An AS is a collection of prefixes with a consistent
> and common routing policy.  By definition, an AS must be a
> contiguous collection of prefixes or it is not properly a
> single AS.  Using the same ASN to represent multiple AS is
> a clear violation.
> 
> It doesn't fit the RFC definition of AS.  Therefore, there is no
> reason to support such usage on a continuing basis.  You violate
> the RFC's you takes your chances.

I guess all those root servers that use the same asn
but connect to different networks (anycast) should get shut down
quickly.

This is a part of networking life today in the v4 space,
and without any current changes, it will (is) the same in v6
routing as there is nothing different except a few more bits 32 => 128.

No new routing protocol, nothing, except this shim6 thing
which people don't seem interested in because it means network
operators can't do the traffic engineering they need to.

- jared

-- 
Jared Mauch  | pgp key available via finger from [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

Re: shim6 @ NANOG (forwarded note from John Payne)

[Iljitsch van Beijnum]

Man, I hope I never become as cynical as you.

On 2-mrt-2006, at 11:09, Stephen Sprunk wrote:

Why is it even remotely rational that a corporate admin trust 100k+  
hosts infested with worms, virii, spam, malware, etc. to handle  
multihoming decisions?


They trust those hosts to do congestion control too, which is even  
more important.



Especially when we don't even have a sample of working code today?


The IAB goes out of its way to solicit input on ongoing work, and now  
you whine about lack of working code?


Now, some may take that as a sign the IETF needs to figure out how  
to handle 10^6 BGP prefixes...  I'm not sure we'll be there for a  
few years with IPv6, but sooner or later we will, and someone needs  
to figure out what the Internet is going to look like at that point.


It won't look good. ISPs will have to buy much more expensive  
routers. At some point, people will start to filter out routes that  
they feel they can live without and universal reachability will be a  
thing of the past.


It will be just like NAT: every individual problem will be solvable,  
but as an industry, or even a society, we'll be wasting enormous  
amounts of time, energy and money just because we didn't want to bite  
the bullet earlier on.

Re: shim6 @ NANOG (forwarded note from John Payne)

[Mark Newton]

On Thu, Mar 02, 2006 at 03:51:43PM +0100, Iljitsch van Beijnum wrote:

 > >Now, some may take that as a sign the IETF needs to figure out how  
 > >to handle 10^6 BGP prefixes...  I'm not sure we'll be there for a  
 > >few years with IPv6, but sooner or later we will, and someone needs  
 > >to figure out what the Internet is going to look like at that point.
 > 
 > It won't look good. ISPs will have to buy much more expensive  
 > routers. At some point, people will start to filter out routes that  
 > they feel they can live without and universal reachability will be a  
 > thing of the past.

But don't we filter out routes we feel we can live without *right now*
without the world ending?

I mean, who accepts prefixes longer than /24 these days anyway?
We've all decided that we "can live without" any network smaller
than 254 hosts and it hasn't made a lick of difference to 
universal reachability.

What's to stop someone who wants to carry around less prefixes from
saying, "Bugg'rit, I'm not going to accept anything smaller than 
a /18"?

  - mark

-- 
Mark Newton   Email:  [EMAIL PROTECTED] (W)
Network Engineer  Email:  [EMAIL PROTECTED]  (H)
Internode Systems Pty Ltd Desk:   +61-8-82282999
"Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223

Re: shim6 @ NANOG (forwarded note from John Payne)

[Michael . Dillon]

> So learn to love shim6 or help create something better. Complaining 
> isn't going to solve anything.

I am helping to create something better by supporting
the IPv6 PI address policy on [EMAIL PROTECTED]

Go here http://www.arin.net/mailing_lists/index.html
to subscribe or to read the archives. 

To read the proposed policy that is under discussion
go here http://www.arin.net/policy/proposals/2006_4.html
This policy will be voted on at one of the Public 
Policy days (April 10th and 11th) at the next
ARIN meeting in Montreal.

--Michael Dillon

Re: shim6 @ NANOG (forwarded note from John Payne)

[Iljitsch van Beijnum]

On 2-mrt-2006, at 16:20, Mark Newton wrote:


Now, some may take that as a sign the IETF needs to figure out how
to handle 10^6 BGP prefixes...  I'm not sure we'll be there for a
few years with IPv6, but sooner or later we will, and someone needs
to figure out what the Internet is going to look like at that point.



It won't look good. ISPs will have to buy much more expensive
routers. At some point, people will start to filter out routes that
they feel they can live without and universal reachability will be a
thing of the past.



But don't we filter out routes we feel we can live without *right now*
without the world ending?


Did I say that the world would end? All of this is important stuff  
but fortunately not THAT important...



I mean, who accepts prefixes longer than /24 these days anyway?
We've all decided that we "can live without" any network smaller
than 254 hosts and it hasn't made a lick of difference to
universal reachability.


...because everyone who can't get a /24 will find another way to  
connect to the internet. Now suppose that today we all filter at /24  
but tomorrow we start...



What's to stop someone who wants to carry around less prefixes from
saying, "Bugg'rit, I'm not going to accept anything smaller than
a /18"?


This will break connectivity to MANY parts of the internet. And yes,  
you can do this if you want. Your customers may not like the new  
policy, though. A more realistic scenario would be to go from /24 to / 
23, which will make your routing tables a lot smaller but not break  
_too_ much. If enough people start doing this, people who have a /24  
will have to renumber into a larger block or move to PA space. And  
two years later it's /22 and so on. At this point, the people at the  
short end of that stick may start to think that shim6 wasn't so bad  
after all.


Note that in IPv6 all of this will play out differently because you  
basically have /32s for most ISPs (some shorter ones as well of  
course, but no longer ones for ISPs) So filtering on prefix length  
(other than as a safety mechanism against accidental deaggregation)  
won't be useful. Today you can deaggregate a /16 into 256 /24s, but  
deaggregating a /32 into 65536 /48s is of course more problematic.


But maybe in IPv6 people will filter out stuff from other regional  
registries. Especially when they discover multihoming in Asia.

Re: shim6 @ NANOG (forwarded note from John Payne)

[Michael . Dillon]

> If all of your hosting is "shared", the servers are your 
> responsibility, and you're not providing connectivity to anyone but 
> yourself. I don't think you qualify at all at this point.
> 
> If you're selling dedicated servers or colo space, it's a little 
> better, but I still don't think you fit. The average dedicated 
> hosting/colo company now runs many customers servers sharing one 
> subnet. Each customer gets /32's assigned per server, unless you're a 
> huge colo customer, you're not getting space SWIPed to you.

If your current business model means that your business
cannot continue in an IPv6 world, then a competent
business manager will change that model. If the IPv6
address policy requires hosting providers to sell the
blades in their servers, and to SWIP a /48 per customer
end-site (i.e. blade) then they will do so. There is
precedent for this when IPv4 addressing policy drove
hosting providers to name-based virtual hosting.

I'm not terribly worried about situations like this 
because I know the applicants can adjust their business
plans, and future business models, to work with the policy.
A while back on PPML I noted that RIPE had allocated 
IPv6 space to several organizations with no IPv4 allocations.
Under the assumption that these were not existing IPv4
ISPs, I had a look into several of these organizations.
One of them was the IT function of a retail chain operating
in Germany, Poland and Turkey. If they could qualify as
an LIR by organizing their business with a separate 
IT and network services function, then I think the rules
are less restrictive than most people think.

If you feel you should qualify as an LIR, then apply
for your /32. If you get rejected, asked for detailed
reasons why. If the reasons are due to misunderstanding
or a lack of information, then remedy the situation and
reapply. If the reasons have to do with your structure or
your plans, then change them and reapply. If you can't do
that then I would question whether you have a serious
intention to be an IPv6 service provider.

> > - /128 when it is absolutely known that one and only one device is 
> > connecting.
> 
> One customer on one dedicated server gets a /128.

You know, the problem with those blade servers is that
they generate too much heat and use too much electricity
in one place. This increases HVAC costs and increase the
risk of power problems. It also creates a massive downside 
during a power outage if you can't keep the HVAC running.
Much better to find a cheaper real-estate location where 
you can rent rack positions rather than blades. Customers
can put whatever they want in their rack positions. Maybe
it's a WLAN proxy relay station or their own blade server.
You can't know how many devices will be at the rack position
therefore you should allocate them a /48. After all, you
are a hotel. You rent rooms, you don't police what goes on
inside the room.

> The other PI assignment policies that have been proposed either 
> require that you have a /19 already in IPv4 (lots of hosting 
> companies don't have anything this size), or have tens/hundreds of 
> thousands of devices.

It has also been suggested that the simple presence of
multihoming should be sufficient justification for PI space.

> Even if a hosting company does get a /32 or a /44 or whatever, the 
> "you can't deaggregate your assignment at all" policy rules out 
> having multiple independent POPs unless you somehow arrange to get 
> multiple allocations(which isn't possible now).

People have done creative things with tunnels in the past. 
The widespread existence of MPLS backbones makes that 
even easier. You will always be able to find one situation
that simply will not fit a given policy. Regardless, we still
need to have some reasonable policy that creates a level
playing field, does not unecessarily restrain trade, and
creates possibilities that smart entrepreneurs can exploit
to expand the network.

--Michael Dillon

Re: shim6 @ NANOG (forwarded note from John Payne)

[Daniel Golding]

On 3/2/06 7:57 AM, "Edward B. DREGER" <[EMAIL PROTECTED]>
wrote:

> 
>> Date: Thu, 2 Mar 2006 10:07:33 +
>> From: [EMAIL PROTECTED]
> 
> [ snip ]
> 
>> Is there something inherently wrong with independent
>> organizations deciding where to send their packets?
> 
> 1. Many a transit seems to think so.
> 2. Is there an inherent need?
> 3. Is this DPA+sourceroute cocktail the best method?
> 

What Eddy said and also: The designers of shim6 seem to live in a different
network security world than I do. Even assuming that shim6 ever gets
deployed, which is pretty close to complete fantasy, the threat of a massive
TE botnet being used to control large amounts of Internet traffic is a
serious threat to Internet stability. Right now, DDoS attacks from Botnets
are bad enough. Think about what happens when they have source routing
control. 

Shim6 is a non-starter. A critical mass of host OS's will not get their
software upgraded to support this in the next 5 years - there isn't running
code ANYWHERE. Time to stop screwing around.

There is a tremendous amount of effort being wasted here arguing against it
and even more so in the IETF, where time being wasted on shim6 could be
better spent on a new IDR paradigm.

Where is the IETF leadership?

> 
> Eddy
> --
> Everquick Internet - http://www.everquick.net/
> A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
> Bandwidth, consulting, e-commerce, hosting, and network building
> Phone: +1 785 865 5885 Lawrence and [inter]national
> Phone: +1 316 794 8922 Wichita
> 
> DO NOT send mail to the following addresses:
> [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED]
> Sending mail to spambait addresses is a great way to get blocked.
> Ditto for broken OOO autoresponders and foolish AV software backscatter.

-- 
Daniel Golding

Re: shim6 @ NANOG (forwarded note from John Payne)

[Iljitsch van Beijnum]

On 2-mrt-2006, at 17:05, [EMAIL PROTECTED] wrote:


If you feel you should qualify as an LIR,


With RIPE, an LIR is simply an organization that pays the membership  
fee and thus gets to submit requests for address space and AS  
numbers. ARIN doesn't seem to use this terminology except in their  
IPv6 address allocation policy.


--
I've written another book! http://www.runningipv6.net/

New IP to ASN Mapping Services

[Stephen Gill]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[ Apologies to those who receive this post in  multiple forums. ]

Team Cymru is happy to announce the availability of various service
options dedicated to mapping IPv4 numbers to BGP prefixes and ASNs.
These services come in various flavors, including:

* Whois, DNS, HTTP, HTTPS

Each of the services is based on the same BGP feeds from 50+ BGP
peers, and is updated at 4 hour intervals.

Using a single IP or ASN one can obtain any of the following
information:

* BGP Origin ASN
* BGP Peer ASN
* BGP Prefix
* Prefix Country Code (assigned)
* Prefix Registry (assigned)
* Prefix Allocation date
* ASN Country Code (assigned)
* ASN Registry (assigned)
* ASN Allocation date
* ASN Description

The country code, registry, and allocation date are all based off
of data obtained directly from the regional registries including:
ARIN, RIPE NCC, AFRINIC, APNIC, LACNIC. The information returned
relating to these categories will only be as accurate as the data
present in the RIR databases.  The ASN descriptions are based off
of data obtained from cidr-report.

For a summary on how to use these services please visit the
following web page:



If you have any comments, questions, or suggestions please feel free
to contact us at: [EMAIL PROTECTED]

- -- 
Cheers,
Steve, Team Cymru.
http://www.cymru.com

-BEGIN PGP SIGNATURE-
Version: PGP 8.1

iQA/AwUBRAcT63px0HyV1krbEQL4kwCfVtXJyDTNY21pAr0SB7b74IvvxmAAnjkE
Dea4giltBwL7k9GbkQdcbM8E
=15Dj
-END PGP SIGNATURE-

Re: How do you handle client contact for network abuse/malware compaints etc.?

[chuck goolsbee]

All depends on the client and if I think the abuse is intentional or not. 


If the user knows what he/she is doing and I don't think they are being
malicious then I will send them everything.

If I think they are doing it on purpose I send enough to prove my case
and tell them to knock it off -  before I knock it off for them (or
after - depends on how much damage they are causing).

If they don't have a clue then sending them a bunch of information they
won't understand is pointless.  We either help them clean up the mess or
refer them to someone who can.


Ditto here on all the above. Too often it falls under the latter 
category it seems. Since we're in the hosting/colo business PHP web 
forms seem to be the vast majority of issues lately.


I'd love to know what cluebats or magic bullets are available for 
whacking this particular mole most effectively.




--chuck goolsbee
digital.forest

Re: Notes on design of IPv6 BGP multihoming with special subroute attributes (was - Re: Shim6 vs PI addressing)

[william(at)elan.net]

On Thu, 2 Mar 2006, Iljitsch van Beijnum wrote:

My thinking was that its a big waste of memory (in the global bgp table) to 
announce every IPv6 route in full in particular for cases when its 
sub-allocation and aggregate is already being announced.


Yes, it would be cool if the routers or route servers could automatically 
detect this and clean up the routing table. Unfortunately:


   A --- B
 / \
X Y
 \ /
   C --- D

If X uses 172.16.1.0/24 but A also announces 172.16.0.0/12, then A or B could 
decide to suppress the /24. However, Y will see the /24 through D and C but 
not through B and A, so Y will now send all of its traffic to X through C and 
D.


If you read through my design, it would be that Y should assume that
aggregate as seen from B is always valid path even if it is not directly 
indicated by inclusion of special subroute attribute. This maybe both

good and bad as far as such design goes.

But it maybe possible to do limited bgp multi-homing by having such /48 and 
similar routes included as attributes of the main route, i.e.

 A100:1000::/32 route would appear with extended attributes like
   Subroutes: 0010/16 (2)


Some years ago, I suggested doing this by adding a bitmap to the aggregate 
route: a single bit is enough to convey holes in the aggregate, with two or 
three bits you can also do some traffic engineering. This will get you from a 
/16 aggregate to individual /24s with 32 bytes (1 bit per more specific) or a 
/32 to /48s with 8 kilobytes.


Can be done with bitmaps, but unless aggregate is very well filled with 
sub-allocations, this would be waste of memory too. I think individual 
subroutes is more reasonable as long as each one can be well compacted

(0010/16 is 16-bits for netblock, max 7 bits for netmask).

Such an approach does depend on relatively tight packing of end-users that 
share the same ISPs, though.



All these approaches (especially second one) however certain problems when
you have to consider route security & authorization (i.e. SIDR/SBGP space)


IDR security doesn't come cheap anyway: be prepared to double or quadruple 
your router's memory and install crypto hardware.


Yes, most likely it will require dedicated box to process the security 
data and verify ip routes (Note: in usual way dedicated box might be 
represented as being separate card in the router).


--
William Leibzon
Elan Networks
[EMAIL PROTECTED]

Re: Important Statement to Review for Signing

[Martin Hannigan]

At 08:36 AM 3/2/2006, Seth Johnson wrote:



(Apologies for the political/non-strictly-technical substance of
this post; but I think this group is populated by the right
people who would understand the issue, sign the statement, and
know who all else should be approached.  -- Seth Johnson)

Hello folks,

Please review the important joint statement below, related to the
WIPO Broadcaster's Treaty, and consider adding your signature if
you are an American citizen.  Also make sure those you know who
should sign are also given the opportunity.




I guess the one on one spam didn't work so well.


From: Seth Johnson <[EMAIL PROTECTED]>
Organization: Real Measures
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Initial Signature for Joint Statement?
X-MDaemon-Deliver-To: [EMAIL PROTECTED]
X-Return-Path: [EMAIL PROTECTED]


Dear Mr. Hannigan,

I am conducting an initial round of contacts on a one-to-one
basis, asking a few people to lend their names as initial
signatures on the Joint Statement you will find appended to the
end of this message.










--
Martin Hannigan(c) 617-388-2663
Renesys Corporation(w) 617-395-8574
Member of Technical Staff  Network Operations
   [EMAIL PROTECTED]  

Re: Shim6 vs PI addressing

[Marshall Eubanks]

Does this mean that you support 2005-1, or do you think a new ARIN  
proposal is needed ?


Regards
Marshall Eubanks

On Mar 2, 2006, at 4:28 AM, Andre Oppermann wrote:



Owen DeLong wrote:

Please don't mix up addressing and routing. "PI addressing" as you
mention is addressing. SHIM6 will become a routing trick.


I think that is overly pessimistic.  I would say that SHIM6 _MAY_
become a routing trick, but, so far, SHIM6 is a still-born piece
of overly complicated vaporware of minimal operational value, if any.
Personally, I think a better solution is to stop overloading IDR
meaning onto IP addresses and use ASNs for IDR and prefixes for
intradomain routing only.


Full ACK!  For the IDR we then can use perfect match lookups which
scale very well and pretty cheaply to many millions of table entries.
BGP scales very well too if you've got a decent cpu in your router.
Our OpenBGPD easily does 30 flapping constandly full-feeds with 1  
million

routes each.

Lets get pragmatic and realistic!

--
Andre

2005-1, good or bad? [Was: Re: Shim6 vs PI addressing]

[Andre Oppermann]

Marshall Eubanks wrote:


Does this mean that you support 2005-1, or do you think a new ARIN  
proposal is needed ?


What I'm saying is that we should reconsider parts of IPv6' design
decisions and fix stuff while we can.  Opening the floodgates right
now, which 2005-1 will do, will only cement the current IPv4 way of
doing things with longest-prefix match.  Doing longest-prefix match
for high pps rates and high prefix counts in hardware is complex and
expensive.  Way more so than doing perfect match on 32 bits (giving
4bn routeable slots).


To answer your question: I do support the rationale behind 2005-1
to allow for PI address space according to current IPv4 rules but
I think it is premature right now to make the decision in this way.
Once the first /48 according to it went out we have to support and
carry it forever in the DFZ.  Right now I'm against 2005-1.


We should take a hard look at the current customer requirements and
market drivers and look at either adjustments to current policies or
even certain changes to IPv6 itself to align them.

IMHO we have to find the best cross-section satisfying the following
requirements:

 ) PI space to avoid renumbering when switching ISP's  (independence)

 ) PI space to multi-home with two or more ISP's  (performance/redundancy)

 ) PA space for ISP's to hand out to single-homed customers/consumers

 ) Efficient and cost-effective implementation of DFZ packet forwarding


I'm a strong supporter of the original layered approach where different
functionality resides on different levels of the stack and is not or
only to least possible extent intermixed.  Putting routing decisions
into the transport layer (4) as it is done or proposed with SCTP and
SHIM6 is Total Evilness(tm) in my book.  Topology and such should be
of no concern to transport.  The network layer (3) must handle that
in a transparent and independent fashion.  This allows for future
changes and improvements without having to change everything everywhere.
And to make it clear I'm totally against geo-addressing finer than the
size of RIR regions.


Why should anyone take me seriously?  Well, I'm running a genuine 4-digit
AS number for as long as the RIR assigned it to me amost a decade ago.
And I'm an operating system developer (FreeBSD) working on the network stack.
This way I can claim to see all sides of the dice which helps a lot for the
Big Picture(tm).


--
Andre



Regards
Marshall Eubanks

On Mar 2, 2006, at 4:28 AM, Andre Oppermann wrote:



Owen DeLong wrote:


Please don't mix up addressing and routing. "PI addressing" as you
mention is addressing. SHIM6 will become a routing trick.


I think that is overly pessimistic.  I would say that SHIM6 _MAY_
become a routing trick, but, so far, SHIM6 is a still-born piece
of overly complicated vaporware of minimal operational value, if any.
Personally, I think a better solution is to stop overloading IDR
meaning onto IP addresses and use ASNs for IDR and prefixes for
intradomain routing only.



Full ACK!  For the IDR we then can use perfect match lookups which
scale very well and pretty cheaply to many millions of table entries.
BGP scales very well too if you've got a decent cpu in your router.
Our OpenBGPD easily does 30 flapping constandly full-feeds with 1  
million

routes each.

Lets get pragmatic and realistic!

--
Andre

Re: Shim6 vs PI addressing

[Owen DeLong]

--On March 2, 2006 11:31:51 AM +0100 Jeroen Massar <[EMAIL PROTECTED]> wrote:

> On Thu, 2006-03-02 at 02:21 -0800, Owen DeLong wrote:
>> >> Personally, I think a better solution is to stop overloading IDR
>> >> meaning onto IP addresses and use ASNs for IDR and prefixes for
>> >> intradomain routing only.
>> > 
>> > Did you notice that 32bit ASN's are coming and that IPv4 addresses are
>> > 32bits? :) Which effectively means that we are going to route IPv6 with
>> > an IPv4 address space. Or when one would use the 32bit ASN for IPv4:
>> > routing a 32bit address space with an 32bit routing ID. The mere
>> > difference
>> > 
>> Yes, I am well aware of 32bit ASNs.  However, some things to consider:
>> 
>> 1.   Just because ASNs are 32 bits doesn't mean we'll instantly
>>  issue all 4 billion of them.  The reality is that we probably
>>  only need about 18 bits to express all the ASNs well need for
>>  the life of IPv6, but, 32 is the next convenient size and there's
>>  really no benefit to going with less than 32.
> 
> True. If we would take the 170k routes that are in BGP at the moment
> then a 18bits address space is enough to give every route a dedicated
> ASN. The issue is that there are way more people who might want to
> multihome than that, just take the number of businesses on this planet,
> add some future growth and we'll end up using the 24th bit too quite
> quickly. Which is, according to some people who do routing code, no
> problem at all. Like shim6, see first then believe.
> 
>> 2.   In my current thinking on how to achieve ASN based IDR, we
>>  would not need ASNs for every organization that multihomes,
>>  only for each organization that provides transit.  This
>>  would greatly reduce some of the current and future demand
>>  for ASNs.
> 
> Paper/draft/description/website? :)
> 
Paper: Haven't gotten that far yet.
Draft: Haven't gotten that far yet.
Description: See below
Website: Haven't gotten that far yet.

Description:  This is still knocking around in my head so far.  I've
discussed
and described it to a few folks, but, there are lots of details to work out
yet.

So, this will require a fair amount of imagination on your part, and, it
will
require letting go of a lot of assumptions built on the current dogma and
paradigm.  This is in many ways a completely different paradigm for
interdomain
routing.

Basically, internet routers would come in three flavors:

1.  Intradomain Routers -- Routers which have a default route
and limited or no detailed knowledge of topology beyond
the local ASN.

2.  DFZ Edge Routers -- Routers which participate in the IDR
process ("full BGP feeds") which have adjacencies with
Intradomain Routers.

3.  DFZ Core Routers -- Routers which participate in IDR as
in 2 above, but, which do not have any adjacencies with
routers from category 1 above.

In the long run, routers in category 2 and 3 would only carry prefix
information for routes terminating in the local AS.  For all exterior
routes and peering sessions, only AS PATH data would be exchanged,
without any prefix information. (In the interim, BGP would be unchanged
and routing table bloat would continue to be an issue, but, the routing
process could change on a router-by-router basis without requiring a
"flag day" conversion).

Routers in category 2 would insert an IPv6 extension header of type 53
with a new subtype (yet to be defined, probably 1) which would contain
the Destination ASN for the packet.  The lookup of Prefix->ASN mapping
would be accomplished by a process similar to DNS (See Route Resolvers
below).

Routers in category 2 and 3 would forward packets by the following ruleset:

Is extension header present?

Yes: Is it my local ASN?
(A) Yes: -- Prefix route available?
Yes: Route packet by IGP
No: Perform exterior resolution and rewrite
ASN header if possible.  Otherwise,
drop packet. (see loop prevention
below for details)
(B) No: -- Forward based on ASPATH data to reach AS

No: Resolve ASN -- Local?
Yes: -- Continue process from (A) above
No: -- Insert Extension header and continue
from (B) above.
Unresolvable: -- Drop packet, send Unreachable no route

Route Resolver:

Two new RR types and one new hierarchy would need to be added to DNS.

The RR types would be AS and SIG, which would provide AS data similar
to MX records and Cryptographic Signature data which could be used
to trace the delegation of authority for the prefix back 

needing switch options

[Matt Hess]

I need to find a few options for switches..
My requirements are based on heavy voip traffic so the switch needs to 
support a very high pps rate while not as much in the Gbps realms - 
we're using small codecs. We are looking at supporting > 1M subscribers.
Initially, we will be handling media but down the road most of the media 
will not need to be passed on/across our network.


I'd like to get some recommendations from the list as to vendor/models 
that have been deployed and excellent performance / cost has been achieved.


I've looked at the 3com 8807 and the 7757 kits already - I'm not sure 
they would fit the bill (low pps, fabric speed iffy, fabric fail-over 
time questionable - that's my impression from reading on their site).


Replies off list would probably be best and thanks in advance.

Re: DNS deluge for x.p.ctrc.cc

[Peter]

So I was catching up on old unread nanog mail and I came across YAIGP
(Yet Another Insulting Gadi Post)

Knowing that usenet archives are the great internet intelligence
equalizer, I thought I'd pass along these humorous links.
   
http://groups.google.com/groups/profile?enc_user=qybeTxcfIHYUZ1VU5sHfqG_AKbJWly7yRNrpKyy7Nyz7HbyIyw

(or tiny) http://tinyurl.com/mnbk4

with special attention payed to:

http://groups.google.com/group/comp.fonts/browse_thread/thread/ff0bdfe762f37587/5459fa375754e282?lnk=st&q=%22gadi+evron%22&rnum=347&hl=en#5459fa375754e282
(http://tinyurl.com/nhr2b)
You ever find out how to hack those shell accounts?

and

http://groups.google.com/group/alt.irc.undernet/browse_thread/thread/29ac57045fc32f9/44f9a2c8d9bb13f1#
(http://tinyurl.com/pop8u)
Did you find a nice home for those bots?

Anyway Gadi, please take your vacuous posts elsewhere and I promise
I'll do the same.

Thanks and apologies to everyone for the interruption.
peter

Randy Bush wrote:
>>this would be a fine thread to discuss on dns-operations, which a
>>bunch of you here have already joined.
>>http://lists.oarci.net/mailman/listinfo/
>
>
> i joined but have never seen a message on that list.  and this
> discussion seems useful.  maybe we should not do a gadi?
>
> randy
>

Or a Randy. Oops, you just did.

Re: shim6 @ NANOG (forwarded note from John Payne)

[Owen DeLong]

--On March 2, 2006 3:15:59 PM +0100 Iljitsch van Beijnum
<[EMAIL PROTECTED]> wrote:

> 
> On 2-mrt-2006, at 14:49, [EMAIL PROTECTED] wrote:
> 
>> Clearly, it would be extremely unwise for an ISP or
>> an enterprise to rely on shim6 for multihoming. Fortunately
>> they won't have to do this because the BGP multihoming
>> option will be available.
> 
> I guess you have a better crystal ball than I do.
> 
> One thing is very certain: today, a lot of people who have their own  PI
> or even PA block with IPv4, don't qualify for one with IPv6. While  it's
> certainly possible that the rules will be changed such that more  people
> can get an IPv6 PI or PA block, it is EXTREMELY unlikely that  this will
> become as easy as with IPv4.
> 
Possibly, but, if that is true, then, to that extent, it will delay or
prevent the adoption of IPv6 by those people.

> Ergo: some people who multihome with BGP in IPv4 today won't be able  to
> do the same with IPv6. And if you manage to get a PI or PA block  you
> will very likely find that deaggregating won't work nearly as  well with
> IPv6 as it does with IPv4.
> 
And why would those people consider migrating to IPv6?

> So learn to love shim6 or help create something better. Complaining
> isn't going to solve anything.

I'm trying to create something better.  I doubt many people in the
operational
community will ever learn to love shim6.

Owen


-- 
If it wasn't crypto-signed, it probably didn't come from me.


pgpfiKVFebhS8.pgp
Description: PGP signature

Re: Shim6 vs PI addressing

[Owen DeLong]

--On March 2, 2006 9:37:12 AM -0500 Jared Mauch <[EMAIL PROTECTED]>
wrote:

> On Wed, Mar 01, 2006 at 03:01:22PM -0800, Owen DeLong wrote:
>> >I think you're missing that some people do odd
>> > things with their IPs as well, like have one ASN and 35
>> > different sites where they connect to their upstream Tier69.net
>> > all with the same ASN.  This means that their 35 offices/sites
>> > will each need a /32, not one per the entire asn in the table.
>> > 
>> People who are doing that have not read the definition of the
>> term ASN and there is no reason that the community or public
>> policy should concern itself with supporting such violations
>> of the RFCs.  An AS is a collection of prefixes with a consistent
>> and common routing policy.  By definition, an AS must be a
>> contiguous collection of prefixes or it is not properly a
>> single AS.  Using the same ASN to represent multiple AS is
>> a clear violation.
>> 
>> It doesn't fit the RFC definition of AS.  Therefore, there is no
>> reason to support such usage on a continuing basis.  You violate
>> the RFC's you takes your chances.
> 
>   I guess all those root servers that use the same asn
> but connect to different networks (anycast) should get shut down
> quickly.
> 
No... In the case of anycast, there is a consistent routing policy
for the address.  There are services that don't work because
of that routing policy, but, that's a decision of the service
provider in question.  However, they are using the equivalent
of one /32 per entire ASN, not one per site.

If they are advertising different prefixes from different sites
in an inconsistent manner using the same ASN, that is broken.
That's not what anycast does.

>   This is a part of networking life today in the v4 space,
> and without any current changes, it will (is) the same in v6
> routing as there is nothing different except a few more bits 32 => 128.
> 
Anycast is part of networking life today.  What you described initially
is _NOT_ how anycast works.

Owen

-- 
If it wasn't crypto-signed, it probably didn't come from me.


pgp6jhsnZoR8o.pgp
Description: PGP signature

Re: shim6 @ NANOG (forwarded note from John Payne)

[Owen DeLong]

Please consider also 2005-1 at
http://www.arin.net/policy/proposals/2005_1.html

Owen



pgpg8cW8ERncu.pgp
Description: PGP signature

Re: shim6 @ NANOG (forwarded note from John Payne)

[Owen DeLong]

>> The other PI assignment policies that have been proposed either 
>> require that you have a /19 already in IPv4 (lots of hosting 
>> companies don't have anything this size), or have tens/hundreds of 
>> thousands of devices.
> 
> It has also been suggested that the simple presence of
> multihoming should be sufficient justification for PI space.
> 
Current PI policy in the ARIN region is /22 for IPv4.

>> Even if a hosting company does get a /32 or a /44 or whatever, the 
>> "you can't deaggregate your assignment at all" policy rules out 
>> having multiple independent POPs unless you somehow arrange to get 
>> multiple allocations(which isn't possible now).
> 
> People have done creative things with tunnels in the past. 
> The widespread existence of MPLS backbones makes that 
> even easier. You will always be able to find one situation
> that simply will not fit a given policy. Regardless, we still
> need to have some reasonable policy that creates a level
> playing field, does not unecessarily restrain trade, and
> creates possibilities that smart entrepreneurs can exploit
> to expand the network.
> 
Another option is to create separate ORGs for each colo and get
an allocation for each ORG.

Owen


-- 
If it wasn't crypto-signed, it probably didn't come from me.


pgplNJVTvVywK.pgp
Description: PGP signature

Re: shim6 @ NANOG (forwarded note from John Payne)

[Iljitsch van Beijnum]

On 2-mrt-2006, at 22:27, Owen DeLong wrote:

One thing is very certain: today, a lot of people who have their  
own  PI
or even PA block with IPv4, don't qualify for one with IPv6.  
While  it's
certainly possible that the rules will be changed such that more   
people
can get an IPv6 PI or PA block, it is EXTREMELY unlikely that   
this will

become as easy as with IPv4.



Possibly, but, if that is true, then, to that extent, it will delay or
prevent the adoption of IPv6 by those people.


I agree that this is a possibility.

So I guess we'll have to choose between an IPv6 that's better than  
IPv4 but people don't want it, or an IPv6 that people want but it has  
the same inherent problems as IPv4. Hm...


Ergo: some people who multihome with BGP in IPv4 today won't be  
able  to

do the same with IPv6. And if you manage to get a PI or PA block  you
will very likely find that deaggregating won't work nearly as   
well with

IPv6 as it does with IPv4.



And why would those people consider migrating to IPv6?


Because they can't get IPv4 addresses or so many other people use  
IPv6 (because _they_ can't get IPv4 addresses) that communicating  
with them natively is important.


But today there are still enough IPv4 addresses (I just checked: we  
still have 1444.12 million addresses or 86.08 /8s) so that won't  
happen for a few more years.



So learn to love shim6 or help create something better. Complaining
isn't going to solve anything.



I'm trying to create something better.  I doubt many people in the
operational community will ever learn to love shim6.


Stranger things have happened. Some people actually like NAT...

Re: DNS deluge for x.p.ctrc.cc

[Gadi Evron]

Peter ([EMAIL PROTECTED]) wrote:

You ever find out how to hack those shell accounts?


Any chance you can let Gadi Evron know? :) At least some anonymous 
cowards do some interesting SMTP spoofing.


As to the DNS thread going on over at the DNS-operations mailing list, 
apparently these amplification attacks have been going on for a while 
now (i.e. "longer than we think").


One good thing that may come out of this aside to dealing with badly 
handled recursion is more attention to BCP38 now that somehow people 
believe working on it is important enough.


Two good things out of one bad, I call it a win.

Like Barry Greene said, there are not bad sides or immense costs to 
implementing BCP38. Now that people are believers maybe next time we 
will all be smarter when we have "currently not exploited problems" to 
fix. :o)


Gadi.

Re: 2005-1, good or bad? [Was: Re: Shim6 vs PI addressing]

[Iljitsch van Beijnum]

On 2-mrt-2006, at 21:42, Andre Oppermann wrote:


To answer your question: I do support the rationale behind 2005-1
to allow for PI address space according to current IPv4 rules but
I think it is premature right now to make the decision in this way.
Once the first /48 according to it went out we have to support and
carry it forever in the DFZ.  Right now I'm against 2005-1.


This is in and of itself enough to reject 2005-1, and I urge the ARIN  
constituency to do exactly that. We've had restrictive policies  
around the world for many years now, and so far we've been able to  
live with it. The IETF is making good progress with its multihoming  
in IPv6 efforts: implementable RFCs should be forthcoming within a  
year. Currently, IPv6 deployment is not such that lack of multihoming  
is creating big problems. If this situation changes, a policy  
proposal like this one can presumably be adopted fast enough to avoid  
significant problems.


I've talked long and hard about why it's bad to have nearly  
unrestricted PI in IPv6 because the routing system can't scale  
(either at all or at reasonable cost) to accommodate this, but  
apparently this argument isn't universally convincing among  
operators. However, within the IETF there is reasonable consensus  
that there is enough of a risk to warrant efforts to provide  
multihoming benefits that don't impact routing.


Also, having /48s for PI is a bad choice as it procludes easy  
filtering of accidental deaggregated PA prefixes. ISPs are getting / 
32s or larger, and customers often get a /48. Deaggregating a /32  
into /48s has the potential to increase the global routing table by  
65000 routes. Such an event will almost certainly overload routers  
that don't filter those prefixes out. Experience in IPv4 shows us  
that accidental deaggregation is relatively common. The easiest way  
to avoid problems when this happens is filter out all /48s. Today,  
there must already be exceptions for root server /48s, but as the  
number of exceptions grows the filtes will become more fragile and  
the risk of deaggregation that isn't caught by filters increases.


Finallly, allow me to observe that deciding on this issues regionally  
while the resulting routes must be carried world wide doesn't make  
sense. We really need a global forum for this.

Re: shim6 @ NANOG (forwarded note from John Payne)

[Gustavo Lozano]

At 11:27 AM 3/2/2006 -0500, Daniel Golding wrote:

There is a tremendous amount of effort being wasted here arguing against it
and even more so in the IETF, where time being wasted on shim6 could be
better spent on a new IDR paradigm.

Where is the IETF leadership?



I think the IRTF is the right place to discuss the new IDR paradigm.

http://www.irtf.org/charter?gtype=rg&group=rrg

"This research group is chartered to explore routing problems that 
are important to the development of the Internet but are not yet 
mature enough for engineering work within the IETF. The group will 
work closely with the IESG Routing Area Directors to ensure the free 
flow of information in both directions and avoid duplication of work 
with the various IETF working groups.


The first steps taken in the RRG consisted of conducting a survey the 
state of the art in routing research, the needs of the user community 
(ISPs, router vendors, etc.) and the history of routing requirements. 
While this work will be ongoing as the state of research and of needs 
changes, the next step involves taking a number of the problem 
brought out in the analysis and focusing on these issues.




The current set of sub-groups includes:

Future Domain Routing Scalability"



gus 

Re: 2005-1, good or bad? [Was: Re: Shim6 vs PI addressing]

[Edward B. DREGER]

AO> Date: Thu, 02 Mar 2006 21:42:49 +0100
AO> From: Andre Oppermann

AO> Doing longest-prefix match for high pps rates and high prefix counts
AO> in hardware is complex and expensive.

True, but...


AO> Way more so than doing perfect match on 32 bits (giving 4bn
AO> routeable slots).

...how many routers' FIBs are 32-bit perfect match right now?  Or even a 
24+8 radix tree?

That said, one can use a hybrid

{ array + { btree | skip list } }

for O(k + log(N)) FIB lookups when hardware doesn't support full exact 
match.  Transition workload from logarithmic to scalar as technology 
permits.

Classful routing is simple.  Simplicity is good.  However, it's still 
not quite time to get carried away with huge tables.  (Of course, IPv6 
is a good chance to "start over" with a defragmented table in which a 
full table would have _fewer_ routes than IPv4.)


Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita

DO NOT send mail to the following addresses:
[EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.

Re: shim6 @ NANOG (forwarded note from John Payne)

[Mark Newton]

On Thu, Mar 02, 2006 at 10:44:01PM +0100, Iljitsch van Beijnum wrote:

 > >And why would those people consider migrating to IPv6?
 > 
 > Because they can't get IPv4 addresses or so many other people use  
 > IPv6 (because _they_ can't get IPv4 addresses) that communicating  
 > with them natively is important.
 > But today there are still enough IPv4 addresses (I just checked: we  
 > still have 1444.12 million addresses or 86.08 /8s) so that won't  
 > happen for a few more years.

You've probably seen Geoff Huston's comments about this;  I tend
to agree with him here.

When IPv4 space is exhausted, the sky won't fall;  We'll simply
work out an address space management policy which is different
from the one we have right now.

Right now we can hand them out to anyone who demonstrates a need
for them.  When they run out we'll need to be able to reallocate 
address blocks which have already been handed out from orgs who
perhaps don't need them as much as they thought they did to orgs
which need them more.

Sounds like a marketplace to me.  How much do you think a /24 is
worth?  How many microseconds do you think it'll take for members
of each RIR to debate the policy changes needed to alter their
rules to permit trading of IPv4 resource allocations once IANA
says, "No!" for the first time?

That'll be interesting, because it'll place a cost on not migrating
to IPv6:  If an ISP wishes to grow its business it'll need to have
sufficient resources to buy the address space it needs.  We'll also
have a reasonably good idea of what it'd cost to perform an IPv6 
migration as we gather feedback from orgs who have actually done it.
My guess is that we'll keep using IPv4 until the cost of growing
businesses with the old address space exceeds the cost of migrating
to the new one.

One thing that Geoff hasn't been cynical enough to put forward is
the idea that orgs with lots of valuable, monetized address space
may very well end up lobbying the IAB and RIRs to erect new cost
structures around green-fields IPv6 allocations as well, to make
sure that the profit-providing marketplace survives for as long 
as possible by making the IPv6 migration process as expensive and
inconvenient as possible.  What will happen when the MCI's of the
world discover that the race to $0 for IP transit prices has created
a world in which they make more money by selling their IPv4 addresses
than they make by selling Internet access?  Will we see them coming
out as a strong supporter of restrictive RIR policies and IPv6
technologies which don't work as a way of artificially boosting
the price of IPv6?

It's going to be a fun ride :-)


  - mark

-- 
Mark Newton   Email:  [EMAIL PROTECTED] (W)
Network Engineer  Email:  [EMAIL PROTECTED]  (H)
Internode Systems Pty Ltd Desk:   +61-8-82282999
"Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223

Cogent Outage

[David Coulson]

Apparently Cogent had a fiber cut between Santa Clara and Houston which 
is screwing their network up pretty nicely (I'm seeing 60m of latency 
between two routers in Chicago).


Their internal ticket # is 387128.

Is this the second or third this year for them?

David

Re: Cogent Outage

[Richard A Steenbergen]

On Thu, Mar 02, 2006 at 06:41:04PM -0500, David Coulson wrote:
> 
> Apparently Cogent had a fiber cut between Santa Clara and Houston which 
> is screwing their network up pretty nicely (I'm seeing 60m of latency 
> between two routers in Chicago).

You mean WCG had a fiber cut, just west of Houston. Santa Clara is 
completely and totally unrelated as a destination, on anyone's network. 
This affects far more than Cogent though.

> Their internal ticket # is 387128.
> 
> Is this the second or third this year for them?

Higher.

You can't hold longhaul fiber cuts against Cogent directly though. Stuff 
happens. You CAN hold it against them when a single metro cut takes out 
half of a longhaul crosscountry ring though, or when two simultanious cuts 
segment the network into east and west sides of the country. Thats just 
bad planning. :)

-- 
Richard A Steenbergen <[EMAIL PROTECTED]>   http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Re: shim6 @ NANOG (forwarded note from John Payne)

[Iljitsch van Beijnum]

On 3-mrt-2006, at 0:22, Mark Newton wrote:


You've probably seen Geoff Huston's comments about this;  I tend
to agree with him here.


Geoff tends to make lots of comments, it's hard to either agree or  
disagree with them all.  :-)



When IPv4 space is exhausted, the sky won't fall;  We'll simply
work out an address space management policy which is different
from the one we have right now.


Of course. But don't underestimate how address-hungry some people/ 
organizations/places are. For instance, Comcast got 12.5 million  
addresses last year.



Right now we can hand them out to anyone who demonstrates a need
for them.  When they run out we'll need to be able to reallocate
address blocks which have already been handed out from orgs who
perhaps don't need them as much as they thought they did to orgs
which need them more.



Sounds like a marketplace to me.  How much do you think a /24 is
worth?  How many microseconds do you think it'll take for members
of each RIR to debate the policy changes needed to alter their
rules to permit trading of IPv4 resource allocations once IANA
says, "No!" for the first time?


This is what I wrote about this a couple of months ago: http:// 
ablog.apress.com/?p=835


An interesting aspect about address trading is that some  
organizations have huge amounts of address space which didn't cost  
them anything, or at least not significantly more than what smaller  
blocks of address space cost others. Having them pocket the proceeds  
strikes me as rather unfair, and also counter productive because it  
encourages hoarding. Maybe a system where ARIN and other RIRs buy  
back addresses for a price per bit prefix length rather than per  
address makes sense.


We'll also have a reasonably good idea of what it'd cost to perform  
an IPv6

migration as we gather feedback from orgs who have actually done it.


I don't think the cost is too relevant (and hard to calculate because  
a lot of it is training and other not easily quantified  
expenditures), what counts is what it buys you. I ran a web bug for a  
non-networking related page in Dutch for a while and some 0.16% of  
all requests were done over IPv6. (That's 1 in 666.) So even if it's  
free, deploying IPv6 today isn't all that useful. But when you're the  
last one running IPv4, you'll really want to move over to IPv6, even  
if it's very expensive.

Re: shim6 @ NANOG (forwarded note from John Payne)

[Niels Bakker]

* [EMAIL PROTECTED] ([EMAIL PROTECTED]) [Thu 02 Mar 2006, 17:03 CET]:

If your current business model means that your business
cannot continue in an IPv6 world, then a competent
business manager will change that model. If the IPv6


I assume that you mean that the IPv6 model will be changed, no?  
Because I hope that it has become clear from this thread that the 
adoption of IPv6 by a significant amount of players currently reachable 
over IPv4 is far from certain, and unless IPv6 offers at least feature 
compatibility it may not even happen.



[..]

If you feel you should qualify as an LIR, then apply
for your /32. If you get rejected, asked for detailed
reasons why. If the reasons are due to misunderstanding
or a lack of information, then remedy the situation and
reapply. If the reasons have to do with your structure or
your plans, then change them and reapply. If you can't do
that then I would question whether you have a serious
intention to be an IPv6 service provider.


Why should a certain business model be forced upon you?  To multihome 
right now you need to cough up some money for equipment and some clue 
for configuration.  Why would IPv6 require you to change your business 
model to achieve the same?



[unattributed wrote:]

One customer on one dedicated server gets a /128.


That is, of course, insane.  IPv6 addresses are far from rare.  Why do 
you a priori rule out applications like https and virtualisation?



-- Niels.

Re: shim6 @ NANOG (forwarded note from John Payne)

[Randy Bush]

> Shim6 is an answer to "what kind of multihoming can we offer to sites 
> without PI space?

as far as i can tell, s/sites/hosts/.  to make it work for sites,
as yet unspecified middleware (adding even more complexity and thus
further reducing reliability (and margins)) will be needed if there
is any concern for security and/or site management; and, aside from
the home user, there always are.

randy

Re: Shim6 vs PI addressing

[David Barak]

--- Jared Mauch <[EMAIL PROTECTED]> wrote:
>   I think you're missing that some people do odd
> things with their IPs as well, like have one ASN and
> 35
> different sites where they connect to their upstream
> Tier69.net
> all with the same ASN.  This means that their 35
> offices/sites
> will each need a /32, not one per the entire asn in
> the table.

No, that's an argument for a /32 and a bunch of /48
allocations heard by a single provider, who's getting
paid to carry them, but are not advertised to the rest
of the Internet.

>   And they may use different carriers in different
> cities.  Obviously this doesn't fit the definition
> that some have
> of "autonomous system", as these are 35 different
> discrete networks
> that share a globally unique identifier of sorts.

Well, wait a minute - what would these people do
TODAY?  Some build tunnel backbones, some use one ASN
per city, some do "allowas-in" or other things of that
nature.  I would venture to say that most medium to
large enterprises don't use straight-Internet with no
VPN of any kind to support their enterprise backbones
anymore, simply for security reasons.  

My argument still stands - if having an ASN is equated
with having a routable netblock, then each of those
cases results in the enterprise being able to pass
packets, and only the "one ASN per city" approach
requires multiple netblocks.

-David

David Barak
Need Geek Rock?  Try The Franchise: 
http://www.listentothefranchise.com

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: shim6 @ NANOG (forwarded note from John Payne)

[Marshall Eubanks]

Hello;

On Mar 1, 2006, at 10:45 AM, Joe Abley wrote:




On 1-Mar-2006, at 10:33, John Payne wrote:


On Mar 1, 2006, at 1:52 AM, Joe Abley wrote:

Shim6 also has some features which aren't possible with the swamp  
-- for example, it allows *everybody* to multi-home, down to  
people whose entire infrastructure consists of an individual  
device, and to do so in a scaleable way.


Only if *everybody* has a shim6 capable stack...


Not quite -- the practical usefulness of the multi-homing increases  
with the deployment of shim6-capable stacks. You could imagine a  
threshold of server and host upgrades which would provide useful  
multi-homing a good proportion of the time without universal  
deployment.


If Linux and the currently-supported variants of Windows were to be  
updated to support shim6, and we waited through three or four  
widely-publicised security vulnerabilities which required OS/kernel  
upgrades, perhaps that would be sufficient deployment for the  
benefits of shim6 to be felt, most of the time. My hands are waving  
again, of course.




I have to object to this here; your hands are not waving nearly hard  
enough.


This was exactly the same mistake that was made with IGMPv3, which  
IIRC was
finalized around the time of the Adelaide IETF (i.e., almost exactly  
6 years ago).


1.) It took about 4 years for Windows variants with IGMPv3 support to  
dominate the Windows logs in my web servers.
(By dominate, I mean > 80% of hits from windows machines.) In  
February of this year,
Windows 98 (non IGMPv3 capable) was still 2% of the total web hits,  
compared to 0.56 % for all flavors of Linux and 0.03% for all flavors  
of BSD.


2.) The Mac (8% of web hits in February 2006), still doesn't have it.

3.) So IGMPv3 deployment in hosts _at this instant_ is almost  
certainly less than 90%.


4.) Partially as a result, SSM deployment is still miniscule.

That's after 6 years.

I would be surprised if Shim6 going into actual deployed boxes was  
any faster.  So, if Shim6 was finalized today, which it won't be, in  
2010 we might have 70% deployment and in 2012 we might have 90%  
deployment.


I actually think that 2012 would be a more realistic date for 70%  
deployment of Shim6, given the lack of running code and a finalized  
protocol now.


In my opinion, that doesn't imply that Shim6 should be abandoned. But  
it does mean IMHO that regarding it as a

means to spur IPv6 deployment is just not realistic.

Regards
Marshall Eubanks


I feel fairly certain I have exceeded some kind of unenforced  
posting threshold to this list in the last twelve hours. I will try  
hard to be quiet for a while, now :-)



Joe

Re: 2005-1, good or bad? [Was: Re: Shim6 vs PI addressing]

[Roland Dobbins]

On Mar 2, 2006, at 2:06 PM, Iljitsch van Beijnum wrote:

The IETF is making good progress with its multihoming in IPv6  
efforts: implementable RFCs should be forthcoming within a year.


Which proposals do you consider to be implementable?

--
Roland Dobbins <[EMAIL PROTECTED]> // 408.527.6376 voice

 Everything has been said.  But nobody listens.

   -- Roger Shattuck

Re: 2005-1, good or bad? [Was: Re: Shim6 vs PI addressing]

[Marshall Eubanks]

Hello;

On Mar 2, 2006, at 5:06 PM, Iljitsch van Beijnum wrote:


On 2-mrt-2006, at 21:42, Andre Oppermann wrote:


To answer your question: I do support the rationale behind 2005-1
to allow for PI address space according to current IPv4 rules but
I think it is premature right now to make the decision in this way.
Once the first /48 according to it went out we have to support and
carry it forever in the DFZ.  Right now I'm against 2005-1.


This is in and of itself enough to reject 2005-1, and I urge the  
ARIN constituency to do exactly that. We've had restrictive  
policies around the world for many years now, and so far we've been  
able to live with it. The IETF


2005-1 is fairly close to 2002-3, which has been in place for almost  
3 years, and so far we've been able to live with it.


is making good progress with its multihoming in IPv6 efforts:  
implementable RFCs should be forthcoming within a year. Currently,  
IPv6 deployment is not such that lack of multihoming is creating  
big problems. If this situation changes, a policy proposal like  
this one can presumably be adopted fast enough to avoid significant  
problems.


I've talked long and hard about why it's bad to have nearly  
unrestricted PI in IPv6 because the routing system can't scale  
(either at all or at reasonable cost) to accommodate this, but  
apparently this argument isn't universally convincing among  
operators. However, within the IETF there is reasonable consensus  
that there is enough of a risk to warrant efforts to provide  
multihoming benefits that don't impact routing.




The IETF is at serious risk of being overtaken by events here, in my  
humble opinion. I have just returned from China, where there is a  
serious effort focused on deploying IPv6, and where there are 111  
million Internet users,
most with broadband, according to government statistics. I do not  
think that they and the other people waiting on

IPv6 are going to wait a decade for this to be sorted out.

Also, having /48s for PI is a bad choice as it procludes easy  
filtering of accidental deaggregated PA prefixes. ISPs are getting / 
32s or larger, and customers often get a /48. Deaggregating a /32  
into /48s has the potential to increase the global routing table by  
65000 routes. Such an event will almost certainly overload routers  
that don't filter those prefixes out. Experience in IPv4 shows us  
that accidental deaggregation is relatively common. The easiest way  
to avoid problems when this happens is filter out all /48s. Today,  
there must already be exceptions for root server /48s, but as the  
number of exceptions grows the filtes will become more fragile and  
the risk of deaggregation that isn't caught by filters increases.




This to be honest sounds like the sort of thing that router vendors  
would love to build filters for, much
like dampening routing flaps or rate limiting MSDP storms. After all,  
an ASN going from one address block to 65,000 should be detectable  
automatically. I see no reason why this will lead to the filtering of  
all IPv6

/48's.

Finallly, allow me to observe that deciding on this issues  
regionally while the resulting routes must be carried world wide  
doesn't make sense. We really need a global forum for this.


I fully agree here. Maybe a meeting should be organized in the fall  
of 2006 or early 2007 to discuss this,
either under the auspices of the NRO (http://www.nro.net) or  
independently.


Regards
Marshall

24ghz unlic operations

[Christian Kuhtz]

Anyone here operating p2p links in 24GHz unlic band?  Please contact  
me off list.  Thanks!

Re: shim6 @ NANOG (forwarded note from John Payne)

[Tony Li]

Marshall,

> That's after 6 years.
> 
> I would be surprised if Shim6 going into actual deployed boxes was any
> faster.  So, if Shim6 was finalized today, which it won't be, in 2010 we
> might have 70% deployment and in 2012 we might have 90% deployment.
> 
> I actually think that 2012 would be a more realistic date for 70%
> deployment of Shim6, given the lack of running code and a finalized
> protocol now.
> 
> In my opinion, that doesn't imply that Shim6 should be abandoned. But it
> does mean IMHO that regarding it as a
> means to spur IPv6 deployment is just not realistic.


Sorry, but I'm just not buying the analogy.  The market drivers for IGMP
are somewhat smaller than they are for IPv6.  Yes, it would take a
couple of years for Shim6 to be implemented and depending on where we
hit Redmond's release cycle, actually penetrate a significant number of
hosts.  6 years is probably long, and definitely long if we get a
confluence of panic about the death of v4 plus a strong endorsement
about Shim6 from the IETF.  Consider that the IETF *could* conceivably
require every compliant v6 implementation to include it.  I grant that
that's unlikely and some lesser endorsement is probably more reasonable,
but I don't think that you should underestimate the capability of the
IETF/ISP/vendor/host community to act a bit more quickly, if there is
sufficient motivation.

I suggest that we compromise, split the difference and swag it at 4 years.

Tony

Re: DNS deluge for x.p.ctrc.cc

[Christopher L. Morrow]

On Thu, 2 Mar 2006, Gadi Evron wrote:

> apparently these amplification attacks have been going on for a while
> now (i.e. "longer than we think").

yes, atleast 6 years...

>
> One good thing that may come out of this aside to dealing with badly
> handled recursion is more attention to BCP38 now that somehow people
> believe working on it is important enough.
>

more attention to bcp38... because things changd how?

> Like Barry Greene said, there are not bad sides or immense costs to
> implementing BCP38. Now that people are believers maybe next time we

I'm fairly certain barry didn't say this as he knows well the actual
immense cost to implementing it... anyway, dead thread let's leave it that
way?

Re: shim6 @ NANOG (forwarded note from John Payne)

[David Barak]

--- Tony Li <[EMAIL PROTECTED]> wrote:

>  Consider that the IETF
> *could* conceivably
> require every compliant v6 implementation to include
> it.  

God Forbid.  I somehow don't want my core routers
deciding to speak shim6...


David Barak
Need Geek Rock?  Try The Franchise: 
http://www.listentothefranchise.com

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com