Re: OMB: IPv6 by June 2008

[John Payne]

On Jul 7, 2005, at 1:37 PM, Joe Abley wrote:

My various networked devices each get two addresses in this way. When 
they talk to some remote device that has a shim6 element in its 
protocol stack, I get all the benefits that I would expect to achieve 
by multi-homing: if one provider goes down, I use the other one 
without having to debug anything, or yank any cables, or answer any 
difficult pop-up questions. Sessions that are established before one 
provider dies continue to work afterwards. New sessions start up just 
fine. When the provider comes back on-line, everything continues to 
work. I probably don't even notice that the provider had a problem.


I've only briefly read stuff about shim6... I've seen mention of load 
sharing and redundancy, but what about load unbalancing and redundancy? 
  An end-site with BGP today has lots of control over their outbound 
traffic patterns in particular... maybe I missed something, but I don't 
get how you can maintain this level of control with shim6.  (inbound 
traffic unbalancing is also an issue... but I did read something about 
dynamically exchanging locators which I could see being used to 
unbalance inbound traffic, perhaps with more control than today's BGP 
setup)

Re: Comment - Re: OMB: IPv6 by June 2008

[Todd Vierling]

On Wed, 13 Jul 2005, Joseph T. Klein wrote:

> For any who use IPv6, I am interested in NAT/PT, 6to4, faith and
> DSTM experiences. Drop me a line if your willing to share your data.

I have not touched NAT-PT, faith, or DSTM, as my personal network runs fully
dual-stack, and my personal network's upstream is v4-only.

(This response is on-list due to the comments I have about 6to4, below.)

I have used 6to4 in the past.  However, it seems that there is a lack of
reachable 2002::/16 routes in the v6 backbone, as much of the world seems
currently unreachable to a 6to4 client.  So I now use an explicit tunnel
network from Hurricane Electric's www.tunnelbroker.net.

HOWEVER, I still use 6to4 -- sort of.

My edge router has a 6to4 interface and 2002 address solely for the purpose
of routing packets to 6to4 clients directly via 6to4 encapsulation, rather
than backfeeding through tunnelbroker.net.  This way, even though all my v6
addresses are "native", my outbound packet traffic to 6to4 remote hosts is
typically more direct (and reliable).

I've recommended this type of 6to4 setup (edge router only, just for
outbound packets) to other v6 networks, and it's been implemented in a few
places where I've recommended it.  IMHO, though, it really should be
implemented as widely as possible to help v6 gather traction.  Relying on
2002::/16 backbone routes is not only [apparently] unreliable, but a huge
latency and v6 backbone transit waste.

(And to those who are curious, this setup still conforms to RFC3964,
sections 5.1 and 5.2, with the condition that src_v6 is not in 2002::/16,
but the rest of the security checks are still testable and valid.  Though
this scheme adds a little setup overhead to v6 networks, it should be a "one
shot deal", and can go away if and when v6 becomes nearly ubiquitous.)

> Yeah I know deploying IPv6 on a large scale is an annoying thought,
> but I think some of the resistance to IPv6 is more from "don't
> bother me, I'm busy" than any hard fast technological reason.

I tend to agree.  At the $orkplace I've been slowly working v6 provisions
into a legacy network management tool that covers the whole business
operation, such that we can at some point flip the switch and handle v6 just
the same as we handle v4.

-- 
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Comment - Re: OMB: IPv6 by June 2008

[Joseph T. Klein]

Just spent the evening catching upon NANOG reading.

IPv6, NAT, VoIP, address reclamation and routing scalability all in
one thread - WOW. Truly a nice mix of top NANOG argument.

Even one posting on sloppy IPv6 peering policy!

So how many who write against IPv6 have tried it?

For any who use IPv6, I am interested in NAT/PT, 6to4, faith and
DSTM experiences. Drop me a line if your willing to share your data.

A few years ago I set up my home network with OS X, XP, and FreeBSD
on it to run dual stacked IPv6/IPv4 - Set up a tunnel - The autoconf
works IMHO better than DHCP - I can watch the Kame swim on all
systems.

Yeah I know deploying IPv6 on a large scale is an annoying thought,
but I think some of the resistance to IPv6 is more from "don't
bother me, I'm busy" than any hard fast technological reason.

I do buy the market arguments that it will be driven by customer
demand, especially in the US. I also side with the view that IPv6
appears to be gaining traction.

USG is the 600lb gorilla customer and network provider will
take notice.

I have tasted the IPv6 forum cool-aide, and don't think its all
that bad.

The stuff is starting to work. I am beginning to think that you
soon will be able to swap 6 for 4 and user will not be the wiser.

Perhaps the cool-aide is spiked?
--
Joseph T. Klein

PSTN: +1 414 961 1690 VoIP: +1 414 431 4231 Mobile: +1 414 628 3380

Re: OMB: IPv6 by June 2008

[Bill Stewart]

> > How are people making the case for IPv6 with [VOIP]?
> > With G.711 and 20ms voice samples, with IPv4 you get:

If you're running G.711, you've decided that network bandwidth isn't a
problem for your application.  Percentage of overhead doesn't really
matter - it's total overhead bandwidth compared to available bandwidth
that sometimes matters.   There are several different usage scenarios
where there are different tools available for managing bandwidth
consumption
* LANs - you generally don't care
* Single point-to-point calls between general-purpose Internet
endpoints - bandwidth might matter, depending on the pipe size at each
end, and compression can be useful, but usually the more important
problems on small connections are MTU size (because of the latency of
a 1500 byte packet on a 128kbps upstream) and to some extent
prioritization.
* Multiple simultaneous calls between endpoints on a Layer 1 or Layer
2 network - Voice over Layer 2 Frame or ATM has largely fallen out of
fashion, though it worked well for its day.  IP header compression
from vendors starting with C is generally intended for this
environment - some of the versions also support fragmentation to work
around the MTU size problem, but many of them don't work well for
Frame/ATM interworking.
* Multiple simultaneous calls between a pair of Internet endpoints -
there are trunking-style VOIP protocols such as some of the IAX
versions that let you use one set of IP+Layer4 headers to  carry
multiple voice channels, and these can eliminate most of the per-call
overhead (at least when you have most of your channels active, which
is when it matters.)   There are some other VOIP-call-stacking
protocol approaches that at least let you use one set of IP headers to
carry a bunch of {Layer 4 header + Payload} tuples that reduces some
overhead.
* Multiple simultaneous calls at one endpoint to a bunch of
single-call or few-call endpoints across a general IP network.  At the
big end, the easy approach is to just buy fat pipes, but there are
carriers or applications that use header compression on the access
line, either with PPP headers to an access router or frame relay to an
Internet or MPLS edge router.  Unfortunately, we've mostly found it's
difficult to make those solutions scalable - typically the access
cards that are scalable for carrier-sized networks don't do that in
ASICs, and the router doesn't have enough CPU horsepower to support a
significant number of compression sessions in the main CPU at a
reasonable price (where "reasonable" is defined as "cheaper than
adding another access line and a couple more router cards".)
* Encrypted Voice Sessions - the popular approach is to use IPSEC,
which often requires adding a layer or two of NAT traversal UDP
headers as well, so any complaints about the overhead of IPv4 or IPv6
headers on an 8kbps voice session just get multiplied.  It's much more
efficient to do the encryption at the voice layer (at least for
Internet VOIP, as opposed to enterprise VPNs where all the bits are
getting wrapped in IPSEC anyway.)  SIP supports it, and even some
H.323 versions have it tacked on,  but I've found it very frustrating
how much carrier-scale and large-enterprise VOIP equipment doesn't
support payload encryption, so VOIP carriers either don't encrypt
(leaving VOIP wide open to wiretapping without even the grudging
pretense of protection of some of the CALEA rules), even on the media
connection which is between callers, or it's an option that the
carriers didn't buy/provision/activate/whatever.  Skype at least gets
some credit here (though they're using proprietary protocols and
closed source, so it's impossible to tell whether they've done a
secure implementation  that doesn't leak keying material all over the
place), and the Asterisk PBXs are capable of encrypting voice and
signalling channels for many choices of endpoints.


 Thanks; Bill

Re: OMB: IPv6 by June 2008

[Phillip Vandry]

On Tue, Jul 12, 2005 at 09:35:37PM -0400, David Andersen wrote:
> samples to squeeze into a low bandwidth channel.  Enter IP header 
> compression, which is shockingly effective at compressing IP headers of 
> all sorts... if you've dedicated 128 bits for the address, and it's 
> still just as static as it was in IPv4, it'll compress to just the same 
> amount.  This is an easy technical problem to solve.

IP header compression only works well over a link where you have few
flows (fewer than the number of slots for compression) so my customers
get to save some bandwidth on their access links and I get the
privilege of wasting a lot in the core.

But I certainly take Iljitsch's point: maybe I'm complaining about VoIP,
not about IPv6.

-Phil

Re: OMB: IPv6 by June 2008

[David Andersen]

On Jul 12, 2005, at 1:52 PM, Phillip Vandry wrote:


How are people making the case for IPv6 with popular applications like
voice?

With G.711 and 20ms voice samples, with IPv4 you get:

20 bytes IP + 8 bytes UDP + 12 bytes RTP + 160 bytes payload
20% overhead.

40 bytes IP + 32 bytes shim6 8 bytes UDP + 12 bytes RTP +
160 bytes payload
36.5% overhead

Almost twice as much overhead is a much tougher pill to swallow. I 
would

try to stay with IPv4 as long as I could. Even without adding shim6
into the picture you're taking a significant penalty.


Even standard IP headers are a pretty high overhead for VoIP, 
particularly if you're doing very high compression to try to get the 
samples to squeeze into a low bandwidth channel.  Enter IP header 
compression, which is shockingly effective at compressing IP headers of 
all sorts... if you've dedicated 128 bits for the address, and it's 
still just as static as it was in IPv4, it'll compress to just the same 
amount.  This is an easy technical problem to solve.


  -Dave

Re: OMB: IPv6 by June 2008

[Randy Bush]

> With G.711 and 20ms voice samples, with IPv4 you get:
> 
> 20 bytes IP + 8 bytes UDP + 12 bytes RTP + 160 bytes payload
> 20% overhead.
> 
> Now with IPv6. Say we use shim6 or something like that to implement
> multihoming too. The shim6 header isn't decided yet, but I suppose it's
> got to contain at least a pair of addresses (32 bytes).
> 
> 40 bytes IP + 32 bytes shim6 8 bytes UDP + 12 bytes RTP +
> 160 bytes payload
> 36.5% overhead

hey!  we charge by the byte.  so ipv6 is looking better and better!

Re: OMB: IPv6 by June 2008

[Phillip Vandry]

On Wed, Jul 06, 2005 at 09:46:53PM +0200, Iljitsch van Beijnum wrote:
> It's getting better all the time, but there are still strange bugs in  
> the applications, OSes and even the standards. IPv6 works very well  
> for many things but not so well for others. Fortunately, there is  
> still plenty of time to work out all the kinks before we need IPv6 to  
> step up to the plate. In the mean time, we need SOME IPv6 so that the  
> early adopters can find those kinks, and that part is right on track.

How are people making the case for IPv6 with popular applications like
voice?

With G.711 and 20ms voice samples, with IPv4 you get:

20 bytes IP + 8 bytes UDP + 12 bytes RTP + 160 bytes payload
20% overhead.

Now with IPv6. Say we use shim6 or something like that to implement
multihoming too. The shim6 header isn't decided yet, but I suppose it's
got to contain at least a pair of addresses (32 bytes).

40 bytes IP + 32 bytes shim6 8 bytes UDP + 12 bytes RTP +
160 bytes payload
36.5% overhead

Almost twice as much overhead is a much tougher pill to swallow. I would
try to stay with IPv4 as long as I could. Even without adding shim6
into the picture you're taking a significant penalty.

-Phil

Re: OMB: IPv6 by June 2008

[Iljitsch van Beijnum]

On 12-jul-2005, at 19:52, Phillip Vandry wrote:


In the mean time, we need SOME IPv6 so that the
early adopters can find those kinks, and that part is right on track.



How are people making the case for IPv6 with popular applications like
voice?


Dunno, but it can't be many.


With G.711 and 20ms voice samples, with IPv4 you get:



20 bytes IP + 8 bytes UDP + 12 bytes RTP + 160 bytes payload
20% overhead.


Yes. It gets worse when you add compression.  :-)


Now with IPv6. Say we use shim6 or something like that to implement
multihoming too. The shim6 header isn't decided yet, but I suppose  
it's

got to contain at least a pair of addresses (32 bytes).


I'm still fighting the good fight on that one. Hopefully, there won't  
be a header, and if there is, it's only going to be there when there  
was a failure (ie the multihoming kicked in) and the size would  
almost certainly be 8 bytes. But that's all still up in the air.



40 bytes IP + 32 bytes shim6 8 bytes UDP + 12 bytes RTP +
160 bytes payload
36.5% overhead


Without a shim6 header it would be 60 out of 220, with a shim6 header  
most likely 68 out of 228, so 27% or 30%.


Almost twice as much overhead is a much tougher pill to swallow. I  
would

try to stay with IPv4 as long as I could. Even without adding shim6
into the picture you're taking a significant penalty.


This doesn't so much show an IPv6 problem but rather that voice over  
IP is extremely inefficient. Those TDM guys were on to something...  
Too bad the TDM networks are left to rot in the ground as we speak.  
Mark my words, we're going to regret letting this happen at some  
point in the future.

Re: OMB: IPv6 by June 2008

[Jay R. Ashworth]

On Tue, Jul 12, 2005 at 06:43:17AM +, [EMAIL PROTECTED] wrote:
> > And I'm still holding my breathe to see when a commercial company returns 
> > their /8.   -Hank
> 
>   its already happened... over a dozen have been returned.

I'd like to send thank you cards: who are they?  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth[EMAIL PROTECTED]
Designer+-Internetworking--+--+   RFC 2100
Ashworth & Associates   |  Best Practices Wiki |  |'87 e24
St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274

  If you can read this... thank a system administrator.  Or two.  --me

Re: OMB: IPv6 by June 2008

[Hank Nussbacher]

At 11:52 PM 11-07-05 -0700, william(at)elan.net wrote:



On Tue, 12 Jul 2005 [EMAIL PROTECTED] wrote:



On Tue, Jul 12, 2005 at 08:41:04AM +0300, Hank Nussbacher wrote:


At 12:24 PM 11-07-05 -0400, Rich Emmings wrote:


According to IANA, (http://www.iana.org/assignments/ipv4-address-space)
MIT & MERIT are the two .edu /8 holders on the list.  Stanford turned
their /8 in a while ago.


And I'm still holding my breathe to see when a commercial company returns
their /8.   -Hank


its already happened... over a dozen have been returned.


List that dozen blocks please or I'll not believe it.
(I can only see 3 blocks that have been returned)


Why then single out Stanford's 36/8 with "Formerly Stanford University - 
Apr 93" and all other dozen commercial companies remain anonymously returned?


-Hank



--
William Leibzon
Elan Networks
[EMAIL PROTECTED]
+++
This Mail Was Scanned By Mail-seCure System
at the Tel-Aviv University CC.

Re: OMB: IPv6 by June 2008

[william(at)elan.net]

On Tue, 12 Jul 2005 [EMAIL PROTECTED] wrote:



On Tue, Jul 12, 2005 at 08:41:04AM +0300, Hank Nussbacher wrote:


At 12:24 PM 11-07-05 -0400, Rich Emmings wrote:


According to IANA, (http://www.iana.org/assignments/ipv4-address-space)
MIT & MERIT are the two .edu /8 holders on the list.  Stanford turned
their /8 in a while ago.


And I'm still holding my breathe to see when a commercial company returns
their /8.   -Hank


its already happened... over a dozen have been returned.


List that dozen blocks please or I'll not believe it.
(I can only see 3 blocks that have been returned)

--
William Leibzon
Elan Networks
[EMAIL PROTECTED]

Re: OMB: IPv6 by June 2008

[bmanning]

On Tue, Jul 12, 2005 at 08:41:04AM +0300, Hank Nussbacher wrote:
> 
> At 12:24 PM 11-07-05 -0400, Rich Emmings wrote:
> 
> >According to IANA, (http://www.iana.org/assignments/ipv4-address-space) 
> >MIT & MERIT are the two .edu /8 holders on the list.  Stanford turned 
> >their /8 in a while ago.
> 
> And I'm still holding my breathe to see when a commercial company returns 
> their /8.   -Hank


its already happened... over a dozen have been returned.
--bill
> 
> 
> 
> >Many?
> >
> >
> >On Fri, 8 Jul 2005, Daniel Golding wrote:
> >
> >>Rubbish. Many of the organizations that hold legacy /8s are Universities. 
> >>If
> >>a .edu can pick up even a few million dollars from selling off a class A,
> >>they will. After all, they could simply sell chunks.
> >+++
> >This Mail Was Scanned By Mail-seCure System
> >at the Tel-Aviv University CC.

Re: OMB: IPv6 by June 2008

[Hank Nussbacher]

At 12:24 PM 11-07-05 -0400, Rich Emmings wrote:

According to IANA, (http://www.iana.org/assignments/ipv4-address-space) 
MIT & MERIT are the two .edu /8 holders on the list.  Stanford turned 
their /8 in a while ago.


And I'm still holding my breathe to see when a commercial company returns 
their /8.   -Hank





Many?


On Fri, 8 Jul 2005, Daniel Golding wrote:


Rubbish. Many of the organizations that hold legacy /8s are Universities. If
a .edu can pick up even a few million dollars from selling off a class A,
they will. After all, they could simply sell chunks.

+++
This Mail Was Scanned By Mail-seCure System
at the Tel-Aviv University CC.

Re: OMB: IPv6 by June 2008

[Rich Emmings]

According to IANA, (http://www.iana.org/assignments/ipv4-address-space) MIT 
& MERIT are the two .edu /8 holders on the list.  Stanford turned their /8 
in a while ago.



Many?


On Fri, 8 Jul 2005, Daniel Golding wrote:


Rubbish. Many of the organizations that hold legacy /8s are Universities. If
a .edu can pick up even a few million dollars from selling off a class A,
they will. After all, they could simply sell chunks.

Re: OMB: IPv6 by June 2008

[Michael Loftis]

--On July 9, 2005 10:42:57 AM -0700 Alexei Roudnev <[EMAIL PROTECTED]> wrote:



LC can hold only 20,000 ACTIVE routes., and ask central system if it
needs more., How many ACTIVE routes are used in any CORE router?
0.1% or CORE? 2% of CORE?

Again, today it is not technical issue anymore.


Caches arent' necessarily a good idea again because of the miss issue and 
at OC192 speeds it's nutsyou pretty much have to carry a full table 
because if you don't the first time you get a DDoS or a DoS with lots of 
forged sources or dests flowing through your router it'll blow up.

Re: OMB: IPv6 by June 2008

[Alexei Roudnev]

No one real DOS attack can create traffic, sugnificant for core routers
(except one - two worm cases when millions of computers generated random
traffic). I do not see a problem there.

All problems you are talking about are resolved in modern CPU industry,
resolved in modern servers, Router vendors just never had such task. Notice,
that modern routers are MORE THEN anough for modern Internet. If routing
tables grouth 10 times, routers will follow this trend without sugnificant
difficulties.

IPv6 looks exactly as ASN.1 - when Telco created it many years ago, they
attempted to pack everything into very slow 9600 bandwidth. Result - when
you see it in H.323 today, running on 100Mbit links, it's all unnecessary
(and it explains why SIP substitutes H.323, even if it never used excellent
ASN.1 packing schema /do not bite me, there are many other reasons, of
course/).

The same here. Many many years ago it looks as CIDR is 100% required and as
MH can not be achieved for small companies and that we must limit Internet
size to 100,000 routes. Today, we have much more, and do not foresee any
problem related to route table sizes.

I am not saying that Ipv4 mh approach is excellent, but I do not see anyone,
who proved that it could not work in future networks, instead of twisty and
tricky IPv6 addressing schema without MH at all. (Of course, it all will
result in the same trick - every smalll entity in IPv6 will have it's own PI
address block, no one idiot will be able to live with constant renumbering
they proposed to use. Just wait 2 - 10 years and you will see).


- Original Message - 
From: "Dave Andersen" <[EMAIL PROTECTED]>
To: "Alexei Roudnev" <[EMAIL PROTECTED]>; "Syed Junaid Farooqi"
<[EMAIL PROTECTED]>; "Christopher L. Morrow"
<[EMAIL PROTECTED]>
Cc: "NANOG" ; "Brad Knowles" <[EMAIL PROTECTED]>
Sent: Saturday, July 09, 2005 11:34 AM
Subject: Re: OMB: IPv6 by June 2008


> A cache-based architecture of the sort you describe is prone to thrashing
> under weird traffic patterns (such as those introduced by DoS attacks...).
> There's something to be said for having routers that can forward at or
near
> line-rate regardless of the traffic patterns, packet sizes, etc.  If
you're
> holding 1% of your routing table in core, and it takes you several packet
> transmissions worth of time to go off-card to fetch different routing
> entries, you have a pretty serious problem.
>
> Thankfully, nobody ever tries to scan the entire 'net, causing major
> thrashing in lookup tables.  [...]
>
> Also, keep in mind that memory is either big and cheap -- in which case
> you're creating a size problem for routers that already take up enormous
> amounts of space -- or small, fast, and very expensive.  Memory,
> particularly static ram, is also a power hog.  Todays BFRs dissipate about
> as much power as my electric stove on full blast.
>
> If there are architectural solutions that can reduce the cost, size, and
> power consumption of routers while simultaneously providing improved
> availability, it seems silly to ignore them.
>
>   -d
>
> ----- Original Message - 
> From: Alexei Roudnev
> To: Syed Junaid Farooqi ; Christopher L. Morrow
> Cc: NANOG ; Brad Knowles
> Sent: Saturday, July 09, 2005 1:42 PM
> Subject: Re: OMB: IPv6 by June 2008
>
>
> LC can hold only 20,000 ACTIVE routes., and ask central system if it needs
> more., How many ACTIVE routes are used in any CORE router?
> 0.1% or CORE? 2% of CORE?
>
> Again, today it is not technical issue anymore.
> - Original Message - 
> From: Syed Junaid Farooqi
> To: Christopher L. Morrow
> Cc: Alexei Roudnev ; NANOG ; Brad Knowles
> Sent: Saturday, July 09, 2005 1:02 AM
> Subject: Re: OMB: IPv6 by June 2008
>
>
> Christopher L. Morrow wrote:
> randy already asked for a kibosh on the lunacy here... I agree, it'd be
> nice, but...
>
> On Fri, 8 Jul 2005, Alexei Roudnev wrote:
>
>
> You do not need to - any router have only `1 - 10% of all routing table
> active, and it is always possible to optimize these alghoritms.
>
>
>
> and routing vendor's haven't already done some optomizing you think?
>
>
> They sure have, let me explain a bit - Optimization here can be is Route
> table optimization, forwarding table optimization and the actual
forwarding
> lookup paradigm.
> But having the best and most opitmized algorithm makes no difference if
> there is not enough memory on the Line Card, having said that - 1G to 2G
mem
> is something that is already supported by a few vendors - on the Line
cards
> and 2G and above on the Processors (route processor..?)
>
>
> On the other hand - what's wrong with 4Gb on line card in big core r

Re: OMB: IPv6 by June 2008

[David Lesher]

>From safely on the sidelines; I have a minor point to interject into
the tale. See, I've heard that OMB's official's name mentioned in
regards to some other projects -- usually prefixed by "^*&^#%@&^#$"
or similar bits.

Before you hock the kids' college fund to invest in [IPV6
supplier's IPO]; consider that many such strategic plans
end up being buried in unmarked graves, well away from the
press. 

And this being ItB {Inside the Beltway} many a news release/leak
is really a stalking horse, and/or a diversion worthy of a good
magician...



-- 
A host is a host from coast to [EMAIL PROTECTED]
& no one will talk to a host that's close[v].(301) 56-LINUX
Unless the host (that isn't close).pob 1433
is busy, hung or dead20915-1433

Re: OMB: IPv6 by June 2008

[Stephen J. Wilcox]

On Sat, 9 Jul 2005, [EMAIL PROTECTED] wrote:

> On Sat, 09 Jul 2005 18:14:48 BST, "Stephen J. Wilcox" said:
> > forget the talk of juniper t320s in the core.. you are talking about the
> > problem caused by multihoming and multihoming prefixes are not originated
> > typically by such large and expensive routers but by small cheap systems at
> > the edge.
> 
> Yes, but how well does that multihoming work if the Junipers in the core
> can't/ won't carry your announcement? Currently, multihoming only works
> because it's cost-shifting - the pain of carrying the announcement is felt by
> the carriers, not the originators.

sorry, my point was perhaps unclear.. it was suggested that the increasing
requirements to operate routers would be a natural prevention to multihoming.. i
am saying that it is not the multihomers at the edge feeling that pain it is
those already in the core

Steve

Re: OMB: IPv6 by June 2008

[Alexei Roudnev]

LC can hold only 20,000 ACTIVE routes., and ask central system 
if it needs more., How many ACTIVE routes are used in any CORE 
router?
0.1% or CORE? 2% of CORE? 
 
Again, today it is not technical issue anymore.

  - Original Message - 
  From: 
  Syed Junaid 
  Farooqi 
  To: Christopher L. Morrow 
  Cc: Alexei Roudnev ; NANOG ; Brad Knowles 
  Sent: Saturday, July 09, 2005 1:02 
  AM
  Subject: Re: OMB: IPv6 by June 2008
  Christopher L. Morrow wrote: 
  randy already asked for a kibosh on the lunacy here... I agree, it'd be
nice, but...

On Fri, 8 Jul 2005, Alexei Roudnev wrote:

  
You do not need to - any router have only `1 - 10% of all routing table
active, and it is always possible to optimize these alghoritms.


and routing vendor's haven't already done some optomizing you think?

  They sure have, let me explain a bit - Optimization here 
  can be is Route table optimization, forwarding table optimization and the 
  actual forwarding lookup paradigm.But having the best and most opitmized 
  algorithm makes no difference if there is not enough memory on the Line Card, 
  having said that - 1G to 2G mem is something that is already supported by a 
  few vendors - on the Line cards  and 2G and above on the Processors 
  (route processor..?)
  
On the other hand - what's wrong with 4Gb on line card in big core router?

oh, please please name the router vendor that has 4gb of 'ram'
(tcam/fpga/asic-'memory') on the 'linecard'. Oh, can't come up with one?
One wonders why that is? If the solution were as simple as: "Joe, add
1.21jigawatts of memory to the linecard so we can support +1M routes"
Don't you think the vendor would have done this to get people to stop
bitching at them?
  Now, now, The RAM mentioned in terms of Gb should not 
  be thought, even inadvertently, to have something to do with TCAM/fpga/asic 
  -Memory here can be divided in to 1. forwarding memory , 2. Line card CPU 
  memory, 3. TCAM memory (damn costly stuff )And as for the number of 
  routes to be support -Right now venodrs do support close to 500K routes - ask 
  me to name the vendor (notice i did not say Vendors here) and i will be happy 
  to name.But, yes to do something like 1M routes - ahem mighty tricky stuff 
  aint it, but, does any one have 1M active routes in his table as of today 
  (notice how iam trying to evade commenting ;) you cant haul me for saying 
  this)

It's cheap enough, even today. And we have not 1,000,000 routes yet.


In YOUR network you don't... I'd venture to guess there are quite a few
very large networks with +1M routes in them today.

remember though, I'm the chemical engineer... and I was trained to MAKE
the crack cocaine...

  1M routes, BGP is hope so - and not on a single box i 
  suppose so. come on, 1M +  active routes- it sure would be a killing on 
  the box.Chemical engineer you say,  what a wonderfull world - Iam 
  a pharmacist- fully trained to give an anitdote to cocaine 
  addicts.CIAO 

Re: OMB: IPv6 by June 2008

[Valdis . Kletnieks]

On Sat, 09 Jul 2005 18:14:48 BST, "Stephen J. Wilcox" said:
> forget the talk of juniper t320s in the core.. you are talking about the 
> problem 
> caused by multihoming and multihoming prefixes are not originated typically 
> by 
> such large and expensive routers but by small cheap systems at the edge.

Yes, but how well does that multihoming work if the Junipers in the core can't/
won't carry your announcement? Currently, multihoming only works because it's
cost-shifting - the pain of carrying the announcement is felt by the carriers,
not the originators.



pgpSatJli7QAH.pgp
Description: PGP signature

Re: OMB: IPv6 by June 2008

[Stephen J. Wilcox]

intel systems can do this.

forget the talk of juniper t320s in the core.. you are talking about the 
problem 
caused by multihoming and multihoming prefixes are not originated typically by 
such large and expensive routers but by small cheap systems at the edge.

Steve

On Sat, 9 Jul 2005, Alexei Roudnev wrote:

> 
> It's chiken and egg problem. They do not have 4 Gb, because they do not need
> it_now_. techbnically it is not a problem even today.
> Small RAID systems have 1 Gb RAM easily.
> 
> Line cards do not need so much memory - they can always cache routing
> tables. Just again - it is not _technical_ problem.
> IPv6 addressed problem which do note exists in reality.
> 
> 
> - Original Message - 
> From: "Christopher L. Morrow" <[EMAIL PROTECTED]>
> To: "Alexei Roudnev" <[EMAIL PROTECTED]>
> Cc: "NANOG" ; "Brad Knowles" <[EMAIL PROTECTED]>
> Sent: Friday, July 08, 2005 11:12 PM
> Subject: Re: OMB: IPv6 by June 2008
> 
> 
> >
> >
> > randy already asked for a kibosh on the lunacy here... I agree, it'd be
> > nice, but...
> >
> > On Fri, 8 Jul 2005, Alexei Roudnev wrote:
> >
> > >
> > > You do not need to - any router have only `1 - 10% of all routing table
> > > active, and it is always possible to optimize these alghoritms.
> > >
> >
> > and routing vendor's haven't already done some optomizing you think?
> >
> > > On the other hand - what's wrong with 4Gb on line card in big core
> router?
> >
> > oh, please please name the router vendor that has 4gb of 'ram'
> > (tcam/fpga/asic-'memory') on the 'linecard'. Oh, can't come up with one?
> > One wonders why that is? If the solution were as simple as: "Joe, add
> > 1.21jigawatts of memory to the linecard so we can support +1M routes"
> > Don't you think the vendor would have done this to get people to stop
> > bitching at them?
> >
> > > It's cheap enough, even today. And we have not 1,000,000 routes yet.
> > >
> >
> > In YOUR network you don't... I'd venture to guess there are quite a few
> > very large networks with +1M routes in them today.
> >
> > remember though, I'm the chemical engineer... and I was trained to MAKE
> > the crack cocaine...
> 
> 

Re: OMB: IPv6 by June 2008

[Valdis . Kletnieks]

On Sat, 09 Jul 2005 00:56:29 PDT, Alexei Roudnev said:
> 
> It's chiken and egg problem. They do not have 4 Gb, because they do not need
> it_now_. techbnically it is not a problem even today.
> Small RAID systems have 1 Gb RAM easily.
> 
> Line cards do not need so much memory - they can always cache routing
> tables.

Two words: "cache miss".  And unlike a L1/L2 cache miss in a modern PC, where
the CPU will *wait* for you to fill the cache line, the other end of that OC-192
is still in firehose mode


pgpItkLSJ4v3L.pgp
Description: PGP signature

Re: mh (RE: OMB: IPv6 by June 2008)

[Daniel Senie]

At 03:51 PM 7/7/2005, David Andersen wrote:


On Jul 7, 2005, at 3:41 PM, Andre Oppermann wrote:



Fergie (Paul Ferguson) wrote:
>

I'd have to counter with "the assumption that NATs are going
away with v6 is a rather risky assumption." Or perhaps I
misunderstood your point...


There is one thing often overlooked with regard to NAT.  That is,
it has prevented many network based worms for millions of home
users behind NAT devices.  Unfortunatly this fact is overlooked
all the time.  NAT has its downsides but also upsides sometimes.


Yes, but keep in mind that this benefit is completely unrelated to 
NAT's purpose as an address space extender.  A stateful firewall 
with a very simple rule (permit anything originated from the inside, 
deny anything from outside except a few pesky protocols) would 
accomplish exactly the same goal.


Indeed, the fact that most NAT implementations combine the address 
translation with stateful inspection (given it's the simplest way to 
implement NAPT, IMO), this is the case.




And it would be much easier to punch holes through when you needed to.


No, it's the same. With a stateful inspection firewall operating as a 
transparent bridge or as a router, you still need to specify which 
protocols, ports and addresses to permit. It's exactly the same.



From my perspective, the biggest benefit from home NAT devices is 
that they were a vehicle for delivering such a firewall to millions 
of windows boxes.  Unfortunately, this drug comes with a number of 
harmful side effects, including nausea, blurred vision, and the 
inability to deploy a number of new protocols.


The inability to deploy new protocols is exactly the same in many 
cases for a stateful inspection box on public addresses vs. a 
stateful inspection box doing NAT. The firewall must be aware of the 
protocol to permit it at all, and if there's going to be any hope of 
protecting the less secure equipment behind, those firewall devices 
must understand the details of the protocol. That still requires the 
vendor to do work.


Yes, the address translations still add another layer of trouble in 
that passing endpoint identifiers (which unfortunately are the same 
as IP addresses, given a lack of a host identification mechanism 
other than IP address) creates problems for protocol developers. 
However in most cases a good protocol design can be arrived at which 
does not run into these difficulties. Such ideas were documented some 
time ago by the IETF NAT WG as information to protocol designers.

Re: OMB: IPv6 by June 2008

[Daniel Roesen]

On Fri, Jul 08, 2005 at 09:05:29PM -0400, Joe Abley wrote:
> Other failure modes require a full table (e.g. link failure between
> the ISP and its upstream, or some other partial withdrawal of 
> connectivity).

That's absolutely correct. I've overseen this failure mode.

Consider me embarassed. :-(


BEst regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0

Re: OMB: IPv6 by June 2008

[Randy Bush]

> it is not _technical_ problem.

no, it's a human problem.  some reject clue.

enough is enough.

Re: OMB: IPv6 by June 2008

[Alexei Roudnev]

It's chiken and egg problem. They do not have 4 Gb, because they do not need
it_now_. techbnically it is not a problem even today.
Small RAID systems have 1 Gb RAM easily.

Line cards do not need so much memory - they can always cache routing
tables. Just again - it is not _technical_ problem.
IPv6 addressed problem which do note exists in reality.


- Original Message - 
From: "Christopher L. Morrow" <[EMAIL PROTECTED]>
To: "Alexei Roudnev" <[EMAIL PROTECTED]>
Cc: "NANOG" ; "Brad Knowles" <[EMAIL PROTECTED]>
Sent: Friday, July 08, 2005 11:12 PM
Subject: Re: OMB: IPv6 by June 2008


>
>
> randy already asked for a kibosh on the lunacy here... I agree, it'd be
> nice, but...
>
> On Fri, 8 Jul 2005, Alexei Roudnev wrote:
>
> >
> > You do not need to - any router have only `1 - 10% of all routing table
> > active, and it is always possible to optimize these alghoritms.
> >
>
> and routing vendor's haven't already done some optomizing you think?
>
> > On the other hand - what's wrong with 4Gb on line card in big core
router?
>
> oh, please please name the router vendor that has 4gb of 'ram'
> (tcam/fpga/asic-'memory') on the 'linecard'. Oh, can't come up with one?
> One wonders why that is? If the solution were as simple as: "Joe, add
> 1.21jigawatts of memory to the linecard so we can support +1M routes"
> Don't you think the vendor would have done this to get people to stop
> bitching at them?
>
> > It's cheap enough, even today. And we have not 1,000,000 routes yet.
> >
>
> In YOUR network you don't... I'd venture to guess there are quite a few
> very large networks with +1M routes in them today.
>
> remember though, I'm the chemical engineer... and I was trained to MAKE
> the crack cocaine...

Re: OMB: IPv6 by June 2008

[Christopher L. Morrow]

randy already asked for a kibosh on the lunacy here... I agree, it'd be
nice, but...

On Fri, 8 Jul 2005, Alexei Roudnev wrote:

>
> You do not need to - any router have only `1 - 10% of all routing table
> active, and it is always possible to optimize these alghoritms.
>

and routing vendor's haven't already done some optomizing you think?

> On the other hand - what's wrong with 4Gb on line card in big core router?

oh, please please name the router vendor that has 4gb of 'ram'
(tcam/fpga/asic-'memory') on the 'linecard'. Oh, can't come up with one?
One wonders why that is? If the solution were as simple as: "Joe, add
1.21jigawatts of memory to the linecard so we can support +1M routes"
Don't you think the vendor would have done this to get people to stop
bitching at them?

> It's cheap enough, even today. And we have not 1,000,000 routes yet.
>

In YOUR network you don't... I'd venture to guess there are quite a few
very large networks with +1M routes in them today.

remember though, I'm the chemical engineer... and I was trained to MAKE
the crack cocaine...

Re: OMB: IPv6 by June 2008

[Joe Abley]

On 8 Jul 2005, at 19:26, Daniel Roesen wrote:


On Sat, Jul 09, 2005 at 12:52:35AM +0200, Andre Oppermann wrote:
Multihomed end sites usually get away with receiving only default 
route

or some partial routes from their upstreams. So technically you can
BGP multihome with Cisco 1600 or even smaller easily (dunno where BGP
support is starting to become available).


Technically yes, practically no.  At least not for the purposes people
normally want to multihome.


I cannot confirm this observation from my experience supporting a 
number

of customers with their multihoming setups that I've either designed
myself or supported as part of "managed internet access" solutions.


Multi-homing is a tool used in the real network to protect against 
various failure modes. Some failure modes (e.g. last-mile link failure) 
can receive protection using a small router receiving multiple 
defaults. Other failure modes require a full table (e.g. link failure 
between the ISP and its upstream, or some other partial withdrawal of 
connectivity).


The appropriate architecture depends on the needs of the site in 
question. One size does not fit all.



Joe

Re: OMB: IPv6 by June 2008

[Sean Doran]

Small detail:

On 6 Jul, 2005, at 16:30, David Conrad wrote:

If IPv6 had actually addressed one or more of routing scalability,  
multi-homing, or transparent renumbering


These are the same problem, looked at in different ways.

The issue is: graph-sorting scalability demands abstraction;  
abstraction demands abstraction boundaries; abstraction boundaries  
must be reflected in node names (i.e., locators); nodes are  
physically portable, topologically portable, or both.


To be fair, mass deployment of local wireless LANs for large numbers  
of people with portable equipment they carry with them from meeting  
to hotel room to coffee shop to airport lounge to home would not have  
been the obvious future for anyone in the ROAD process.


However, this is today's reality, and the movement of "named things"  
is more likely to increase than not.


"Stretchy LISes" has mostly hidden the physical portable aspect of  
named things. Bridging is ancient and well-understood.


Logical portability happens too, for individual named things and  
varying-sized collections of them.


The stretchy LIS approach works at a cost of header overhead and  
inefficient traffic flow.   The widespread use of VPNs demonstrates  
this well.


The alternative is to deal with disjunctions between the named thing  
and its topological location.


Model A: you go from office to IETF meeting, the IP address you use  
to talk to the world stays the same, and comes from your office's  
address space.   You use VPN technology to make this happen.


Model B: you go from office to IETF meeting, and the IP address you  
use to talk to the world comes from the IETF meeting's address space.


Now go to your hotel room.   Model A: your socket-like things are  
still bound to the office address, and if you walked briskly enough,  
your sessions are likely still alive when you reconnect to your  
office with the VPN tech.


Model B: oops, you have a new address.   You can't use the old  
address.   Your sessions are very likely toast.   Good thing there  
are tools like screen(1) and restartable ftp!


The difference between A and B is independent of the header formats,  
so long as the named thing normally overloads its identity and location.


Model A allows for a disjunction between the identity and location,  
by bridging through the real topology to connect to a distant  
collection of addresses, abstracted via variable-length prefixes.


Model B does not allow for a disjunction in the absence of a session  
protocol, in which case the session layer identifier is the named  
thing, and the current IP address is the locator.


The session layer does not have to be particularly heavyweight, it  
does not have to be distinctly "above" the network and transport  
layers, it does not have to be the only session support available to  
the other protocols in use between communicating entities.


Integrating renumbering-adaptability within the lower (N/T) has some  
attractions especially with regard to preserving the traditional  
datagram and octet-stream modes, reducing the peer-to-peer  
handshaking in the event of renumbering of one of the parties, and in  
leveraging the current DNS architecture.


It would also eliminate the market need for NAT as a tool to assist  
in -- or avoid -- large-scale simultaneous renumbering as when a  
single-homed site switches ISPs.


Instead, IPv6 dealt with a problem that, for the most part, does  
not immediately affect the US market but which (arguably) does  
affect the other regions.  I guess you can, if you like, blame it  
on the accountants...


People should blame it on the multiplexors.

There is lots of scope for multiplexing address use: not everyone is  
awake and powered on simultaneously; not everyone really does need to  
accept inbound connections from *everywhere*, at least not all the  
time; not everyone needs to run a particular service on the same  
numbered port; some services are fine with uniqueness involving  
network-layer-addresss+protocol+port(+possible other things).


NAT, like other forms of multiplexing the Internet has benefited from  
(e.g. TDM, WDM, time-sharing operating systems, ...), can allow for  
more efficient in one's use of limited resources -- in this case,  
aggregated address space -- in a way accountants seem able to cope  
with.   Yes, TANSTAAFL.


Sean.

Re: OMB: IPv6 by June 2008

[Daniel Roesen]

On Sat, Jul 09, 2005 at 12:52:35AM +0200, Andre Oppermann wrote:
> >Multihomed end sites usually get away with receiving only default route
> >or some partial routes from their upstreams. So technically you can
> >BGP multihome with Cisco 1600 or even smaller easily (dunno where BGP
> >support is starting to become available).
> 
> Technically yes, practically no.  At least not for the purposes people
> normally want to multihome.

I cannot confirm this observation from my experience supporting a number
of customers with their multihoming setups that I've either designed
myself or supported as part of "managed internet access" solutions.

I _did_ see several badly designed setups though that had full tables
(and associated hardware overkill) but didn't need it. Consequence:
wasted money, worse convergence times and routers falling over because
of RAM depletion and fragmentation over time.


Regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0

Re: OMB: IPv6 by June 2008 (OT reminder)

[John Curran]

At 9:46 AM -0400 7/8/05, Someone wrote:
>We can morph the RIRs into ...

As a slight aside and w/o any comment on the particular morph'ing proposed,
I'd like to remind folks that 2 seats on the ARIN Board of Trustees, and 5 seats
on ARIN Advisory Council will be filled later this year, and one of the best 
ways
to "morph" ARIN to meet the needs of the community is the nomination of clueful
folks to serve in these roles.  Nominations are due by July 29th, and additional
information is available at: http://www.arin.net/elections/index.html

Thanks! (and you're being returned to the normal tirade, already in progress... 
:)
/John

Chair, ARIN

Re: OMB: IPv6 by June 2008

[Tony Li]

At the risk of continuing this bad flashback...

> A Cisco "CRS-1 16-SLOT LINE-CARD CHASSIS ROUTE PROCESSOR" comes with
> 4 GB of route memory default size.  Juniper's T320 and T640 come with
> 2 GB of main memory default size.  That should take them to some higher
> number of routes.

No, sorry, that's route processor memory and has nothing to do with the
forwarding table.  Actual forwarding in a distributed architecture has
to be distributed to the line card.  Further, given modern forwarding
rates, typical PC DRAM (50-70ns) is vastly inadequate.  Instead, higher
speed SRAM (2-8ns) is a necessity.  The cost differential between these
two technologies is quite large.

And we won't even open the subject about what that memory is *really*
getting used for.

> On the other hand a large DFZ routing table would simply dampen its
> growth by itself.  If it gets to costly to multihome because of the
> hardware requirements only few would be able to so.  Ergo we have a
> negative feedback system here keeping itself in check.  Case solved
> and closed.

The costs for multihoming are borne by everyone *else* in the network
who has to carry the extra prefixes.  Further, market pressures force
carriers to advertise customer prefixes regardless of the costs to the
remainder of the network.  Case not solved.

Multihoming can never be just a small portion of the growth of the DFZ
table, as multihoming so far appears to be a fixed percentage of the
sites on the net.  Thus, even if we solve all of the single-homed sites
through good aggregation, if we do not solve the multi-homed sites
properly, their numbers will continue along the same growth curve, only
time shifted, and will eventually dwarf the current routing table.

Before we continue this thread, folks might want to reread the CIDR
archives from a decade ago.  We are still having the exact same
argument, with the exact same conclusions and the exact same results.
Yes, the scale has changed slightly, but we are nowhere closer to a true
solution.

Tony

Re: OMB: IPv6 by June 2008

[Andre Oppermann]

Daniel Roesen wrote:

On Sat, Jul 09, 2005 at 12:08:08AM +0200, Andre Oppermann wrote:


On the other hand a large DFZ routing table would simply dampen its
growth by itself.  If it gets to costly to multihome because of the
hardware requirements only few would be able to so.  Ergo we have a
negative feedback system here keeping itself in check.  Case solved
and closed.


Multihomed end sites usually get away with receiving only default route
or some partial routes from their upstreams. So technically you can
BGP multihome with Cisco 1600 or even smaller easily (dunno where BGP
support is starting to become available).


Technically yes, practically no.  At least not for the purposes people
normally want to multihome.

--
Andre

Re: OMB: IPv6 by June 2008

[Brad Knowles]

At 12:08 AM +0200 2005-07-09, Andre Oppermann wrote:


 The biggest routers are being upgraded anyway because of even higher
 link speeds and port desities.


I'm not surprised.  After all, time does march on.

	But it doesn't help if the largest/fastest line cards available 
today are made obsolete overnight by people who have no concept of 
what it costs to route packets at OC-192 or OC-768 line speeds, and 
suggest that all the routers in the world could be replaced by a 
small handful of no-name el-cheapo PCs.



 A Cisco "CRS-1 16-SLOT LINE-CARD CHASSIS ROUTE PROCESSOR" comes with
 4 GB of route memory default size.  Juniper's T320 and T640 come with
 2 GB of main memory default size.  That should take them to some higher
 number of routes.


	Problem is, a Tier-1 provider is still going to have hundreds or 
thousands of routers that have to be upgraded, and there are a number 
of Tier-1s.  Tier-2s aren't quite as bad off, but although they buy 
some transit from the Tier-1s, they still have a lot of private 
peering and they're not that far out of the DFZ themselves.  And the 
Tier-2s have a lot less money to pay for the ultra-expensive forklift 
upgrades for the BFRs and GSRs and all that other mega-million dollar 
equipment.


	Meanwhile, a surprising number of people have to try and get by 
with linecards having only 128MB of RAM, at least according to RFC 
3869.



 On the other hand a large DFZ routing table would simply dampen its
 growth by itself.  If it gets to costly to multihome because of the
 hardware requirements only few would be able to so.  Ergo we have a
 negative feedback system here keeping itself in check.  Case solved
 and closed.


	And Volcanoes nicely solve the population problem for those who 
live too close to them.


--
Brad Knowles, <[EMAIL PROTECTED]>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755

  SAGE member since 1995.  See  for more info.

Re: mh (RE: OMB: IPv6 by June 2008)

[Joseph S D Yao]

On Fri, Jul 08, 2005 at 10:24:22PM +0100, Sean Doran wrote:
> On 7 Jul, 2005, at 21:10, Steven M. Bellovin wrote:
> >Real firewalls pass inbound traffic because a
> >state table entry exists.  NATs do the same thing, with nasty
> >side-effects.  There is no added security from the header-mangling.
> 
> To which Len Bosak quipped a few years ago: "If you don't know its  
> name, you can't curse it".

Sure you can.  For a human entity, get a few hairs from its head or nail
clippings.  For a network entity, get the bits of its externally visible
IP address.

-- 
Joe Yao
---
   This message is not an official statement of OSIS Center policies.

Re: mh (RE: OMB: IPv6 by June 2008)

[Sean Doran]

On 8 Jul, 2005, at 18:34, Fred Baker wrote:


A NAT, in that context, is a stateful firewall that changes the  
addresses, which means that the end station cannot use IPSEC to  
ensure that it is still talking with the same system on the outside.




Only if you define IPSEC narrowly as AH in order to justify this claim.

There are at least two interesting differences between a NAT and a  
stateful firewall deployed in front of hosts with permanent public  
address space.   The first involves attackers knowing the topological  
name of a victim who may be unshielded by the firewall during narrow  
windows offered by the implementation, its operators, or both in  
combination.   The second involves a predictable rendezvous point for  
covert communications channels.


Not all NATs protect against these classes of attack, however an  
implementation that assigns inside-outside mappings with reasonable  
randomness will.  One which also breaks connections on failures (by  
invalidating existing mappings)  is more fail-safe than one that  
tries to preserve existing state across crashes or fat-fingerings.


People who don't make use of an interoperable and well understood  
session protocol resilient against this variety of failure in  
connection-oriented transport communications ("identity/locator  
binding invalidation") will probably disagree as their various long- 
lived sessions terminate abnormally...


Applications-layer protocol writers without a session layer would  
also have to worry about:




attacks on TCP such as RST attacks, data insertion, acknowledge  
hacking, and so on





Planned renumbering may as a side effect result in all of the three  
such "attacks" you explicitly listed.


They may also be flummoxed by having to invent a session layer for an  
application that really wants one, leading to reinventing previously  
discovered gotchas like




in large delay*bandwidth product situations SSH's window is a  
performance limit





Finally:



In other words, a NAT is a man-in-the-middle attack, or is a device  
that forces the end user to expose himself to man-in-the-middle  
attacks. A true stateful firewall that allows IPSEC end to end  
doesn't expose the user to those attacks.





The men in the middle are the I* officers who have refused for more  
than a decade to admit they don't know everything, that market forces  
are not always driven by evil doing architectural impurists with  
nothing to teach their elders (which is incongruous with early I*  
tensions with the former CCITT), or that they have their heads buried  
neck deep in NIH kitty litter (ditto).


A NAT is a tool many people find useful enough to deploy, maintain  
and even pay money for, despite the ready availability of  
substitutable tools, and


The IP (both flavours) network and transport layers are very badly  
designed with respect to host renumbering.   Renumbering has been a  
fact of life since before the early 90s.   There is no as-widely- 
promoted-as-TCP session layer to help mitigate renumbering's  
effects.   There is also institutional resistence to fixing this  
aspect of the design of the N+T layers in I*.


So, people who have actually deployed and run networks where  
renumberings happen, deployed NATs simply  because that was one of  
the only solutions readily and mostly interoperably available to  
them.   It is unsurprising that the voluntary standards organization  
dominated by people who have fought against technology to cope with  
(or even embrace) live renumbering is likewise ridden with loudmouths  
who call NATs "attack"s.


What is it exactly that NATs attack, Fred?

Sean.

Re: OMB: IPv6 by June 2008

[Daniel Roesen]

On Sat, Jul 09, 2005 at 12:08:08AM +0200, Andre Oppermann wrote:
> On the other hand a large DFZ routing table would simply dampen its
> growth by itself.  If it gets to costly to multihome because of the
> hardware requirements only few would be able to so.  Ergo we have a
> negative feedback system here keeping itself in check.  Case solved
> and closed.

Multihomed end sites usually get away with receiving only default route
or some partial routes from their upstreams. So technically you can
BGP multihome with Cisco 1600 or even smaller easily (dunno where BGP
support is starting to become available).


Regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0

Re: mh (RE: OMB: IPv6 by June 2008)

[Sean Doran]

On 8 Jul, 2005, at 18:34, Fred Baker wrote:

A NAT, in that context, is a stateful firewall that changes the  
addresses, which means that the end station cannot use IPSEC to  
ensure that it is still talking with the same system on the outside.


Only if you define IPSEC narrowly as AH in order to justify this claim.

There are at least two interesting differences between a NAT and a  
stateful firewall deployed in front of hosts with permanent public  
address space.   The first involves attackers knowing the topological  
name of a victim who may be unshielded by the firewall during narrow  
windows offered by the implementation, its operators, or both in  
combination.   The second involves a predictable rendezvous point for  
covert communications channels.


Not all NATs protect against these classes of attack, however an  
implementation that assigns inside-outside mappings with reasonable  
randomness will.  One which also breaks connections on failures (by  
invalidating existing mappings)  is more fail-safe than one that  
tries to preserve existing state across crashes or fat-fingerings.


People who don't make use of an interoperable and well understood  
session protocol resilient against this variety of failure in  
connection-oriented transport communications ("identity/locator  
binding invalidation") will probably disagree as their various long- 
lived sessions terminate abnormally...


Applications-layer protocol writers without a session layer would  
also have to worry about:


attacks on TCP such as RST attacks, data insertion, acknowledge  
hacking, and so on


Planned renumbering may as a side effect result in all of the three  
such "attacks" you explicitly listed.


They may also be flummoxed by having to invent a session layer for an  
application that really wants one, leading to reinventing previously  
discovered gotchas like


in large delay*bandwidth product situations SSH's window is a  
performance limit


Finally:

In other words, a NAT is a man-in-the-middle attack, or is a device  
that forces the end user to expose himself to man-in-the-middle  
attacks. A true stateful firewall that allows IPSEC end to end  
doesn't expose the user to those attacks.


The men in the middle are the I* officers who have refused for more  
than a decade to admit they don't know everything, that market forces  
are not always driven by evil doing architectural impurists with  
nothing to teach their elders (which is incongruous with early I*  
tensions with the former CCITT), or that they have their heads buried  
neck deep in NIH kitty litter (ditto).


A NAT is a tool many people find useful enough to deploy, maintain  
and even pay money for, despite the ready availability of  
substitutable tools, and


The IP (both flavours) network and transport layers are very badly  
designed with respect to host renumbering.   Renumbering has been a  
fact of life since before the early 90s.   There is no as-widely- 
promoted-as-TCP session layer to help mitigate renumbering's  
effects.   There is also institutional resistence to fixing this  
aspect of the design of the N+T layers in I*.


So, people who have actually deployed and run networks where  
renumberings happen, deployed NATs simply  because that was one of  
the only solutions readily and mostly interoperably available to  
them.   It is unsurprising that the voluntary standards organization  
dominated by people who have fought against technology to cope with  
(or even embrace) live renumbering is likewise ridden with loudmouths  
who call NATs "attack"s.


What is it exactly that NATs attack, Fred?

Sean.

Re: OMB: IPv6 by June 2008

[Andre Oppermann]

Brad Knowles wrote:


At 10:30 AM -0700 2005-07-08, Matt Ghali wrote:


 You keep using the "entire internet" in your replies, when I was
 under the assumption that we were discussing the inter-provider DFZ.

 The only routers which could possibly be affected by the "prefix
 bloat problem" would be multi-homed and mostly inter-provider, which
 is a small fraction of "all routers on the internet".


They're the biggest and most expensive routers on the Internet, and 
if the routing table were to be allowed to grow without bounds, they 
wouldn't be the only ones that would need to be replaced. Everyone else 
would very soon have the exact same problem.
And there are enough of them that you'd probably spend more money 
upgrading them than upgrading all the other routers in the world.


The biggest routers are being upgraded anyway because of even higher
link speeds and port desities.

A Cisco "CRS-1 16-SLOT LINE-CARD CHASSIS ROUTE PROCESSOR" comes with
4 GB of route memory default size.  Juniper's T320 and T640 come with
2 GB of main memory default size.  That should take them to some higher
number of routes.

On the other hand a large DFZ routing table would simply dampen its
growth by itself.  If it gets to costly to multihome because of the
hardware requirements only few would be able to so.  Ergo we have a
negative feedback system here keeping itself in check.  Case solved
and closed.

--
Andre

Re: mh (RE: OMB: IPv6 by June 2008)

[Sean Doran]

On 7 Jul, 2005, at 21:10, Steven M. Bellovin wrote:



Real firewalls pass inbound traffic because a
state table entry exists.  NATs do the same thing, with nasty
side-effects.  There is no added security from the header-mangling.



To which Len Bosak quipped a few years ago: "If you don't know its  
name, you can't curse it".


Sean.

Re: mh (RE: OMB: IPv6 by June 2008)

[Crist Clark]

Fred Baker wrote:
[snip]
A NAT, in that context, is a stateful firewall that changes the 
addresses, which means that the end station cannot use IPSEC to

> ensure that it is still talking with the same system on the outside.
[snip]

No, you can't use AH, but yes, you can use IPsec through NAT. See RFC3947
and RFC3948. But it is not pretty.
--
Crist J. Clark   [EMAIL PROTECTED]
Globalstar Communications(408) 933-4387

Re: mh (RE: OMB: IPv6 by June 2008)

[Crist Clark]

Jay R. Ashworth wrote:

On Fri, Jul 08, 2005 at 01:15:42PM -0400, David Andersen wrote:


On Jul 8, 2005, at 12:49 PM, Jay R. Ashworth wrote:


On Thu, Jul 07, 2005 at 01:31:57PM -0700, Crist Clark wrote:


And if you still want "the protection of NAT," any stateful firewall
will do it.


That seems a common viewpoint.

I believe the very existence of the Ping Of Death rebuts it.

A machine behind a NAT box simply is not visible to the outside world,
except for the protocols you tunnel to it, if any.   This *has* to
vastly reduce it's attack exposure.


Not really.  Consider the logic in a NAT box:


[ ... ]


and the logic in a stateful firewall:



Sorry.  Given my other-end-of-the-telescope perspective, I was
envisioning an *on-machine* firewall, rather than a box.  Clearly *any*
sort of box in the middle helps in the fashion I alluded to, whether it
NATs or not.


Now I'm confused. Who runs *on-machine* NAT?

I guess that's another nice option for firewalls. It doesn't matter
whether your firewall runs locally or on a remote gateway.

Also, when people here are talking about NAT, note that we are only
talking about many-to-one, overloading, PAT, or whatever you want
to call it. If you are using NAT pools or one-to-one NAT, it buys
you no protection at all unless you add firewalling to the mix.
--
Crist J. Clark   [EMAIL PROTECTED]
Globalstar Communications(408) 933-4387

Re: mh (RE: OMB: IPv6 by June 2008)

[Iljitsch van Beijnum]

On 8-jul-2005, at 19:34, Fred Baker wrote:



A NAT, in that context, is a stateful firewall that changes the  
addresses, which means that the end station cannot use IPSEC to  
ensure that it is still talking with the same system on the  
outside. It is able to use TLS, SSH, etc as transport layer  
solutions, but those are subject to attacks on TCP such as RST  
attacks, data insertion, acknowledge hacking, and so on, and SSH  
also has a windowing problem (on top of TCP's window, SSH has its  
own window, and in large delay*bandwidth product situations SSH's  
window is a performance limit). In other words, a NAT is a man-in- 
the-middle attack, or is a device that forces the end user to  
expose himself to man-in-the-middle attacks.





:-)





A true stateful firewall that allows IPSEC end to end doesn't  
expose the user to those attacks.





I of course couldn't resist, so:

!
ipv6 access-list out-ipv6-acl
 permit ipv6 any any reflect state-acl
!
ipv6 access-list in-ipv6-acl
 evaluate state-acl
 deny ipv6 any any log
!

(don't try this at home, kids: that deny any is dangerous because it  
blocks neighbor discovery)


Unfortunately, IPsec (ESP transport mode) isn't allowed back in:

%IPV6-6-ACCESSLOGNP: list in-ipv6-acl/20 denied 50 2001:1AF8:2:5::2 - 
> 2001:1AF8:6:0:20A:95FF:FEF5:246E, 29 packets


On second thought: how could it? The SPIs for outgoing and incoming  
packets are different. I suppose it would be possible for the  
stateful filter to snoop the ISAKMP protocol and install filter rules  
based on the information found there, but that's obviously not what  
happens.

Re: mh (RE: OMB: IPv6 by June 2008)

[Jay R. Ashworth]

On Fri, Jul 08, 2005 at 01:15:42PM -0400, David Andersen wrote:
> On Jul 8, 2005, at 12:49 PM, Jay R. Ashworth wrote:
> > On Thu, Jul 07, 2005 at 01:31:57PM -0700, Crist Clark wrote:
> >> And if you still want "the protection of NAT," any stateful firewall
> >> will do it.
> >
> > That seems a common viewpoint.
> >
> > I believe the very existence of the Ping Of Death rebuts it.
> >
> > A machine behind a NAT box simply is not visible to the outside world,
> > except for the protocols you tunnel to it, if any.   This *has* to
> > vastly reduce it's attack exposure.
> 
> Not really.  Consider the logic in a NAT box:
[ ... ]
> and the logic in a stateful firewall:

Sorry.  Given my other-end-of-the-telescope perspective, I was
envisioning an *on-machine* firewall, rather than a box.  Clearly *any*
sort of box in the middle helps in the fashion I alluded to, whether it
NATs or not.

Cheers,
-- jra
-- 
Jay R. Ashworth[EMAIL PROTECTED]
Designer  Baylink RFC 2100
Ashworth & AssociatesThe Things I Think'87 e24
St Petersburg FL USA  http://baylink.pitas.com +1 727 647 1274

  If you can read this... thank a system administrator.  Or two.  --me

Re: OMB: IPv6 by June 2008

[Brad Knowles]

At 10:30 AM -0700 2005-07-08, Matt Ghali wrote:


 You keep using the "entire internet" in your replies, when I was
 under the assumption that we were discussing the inter-provider DFZ.

 The only routers which could possibly be affected by the "prefix
 bloat problem" would be multi-homed and mostly inter-provider, which
 is a small fraction of "all routers on the internet".


	They're the biggest and most expensive routers on the Internet, 
and if the routing table were to be allowed to grow without bounds, 
they wouldn't be the only ones that would need to be replaced. 
Everyone else would very soon have the exact same problem.


	And there are enough of them that you'd probably spend more money 
upgrading them than upgrading all the other routers in the world.



 I'm not trying to accuse you of anything, but your arguments are
 beginning to sound like a disingenuous straw-man.


	Maybe a slight exaggeration, I grant you.  But certainly on the 
right order of magnitude.


--
Brad Knowles, <[EMAIL PROTECTED]>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755

  SAGE member since 1995.  See  for more info.

Re: mh (RE: OMB: IPv6 by June 2008)

[Fred Baker]

On Jul 8, 2005, at 9:49 AM, Jay R. Ashworth wrote:
A machine behind a NAT box simply is not visible to the outside world, 
except for the protocols you tunnel to it, if any.   This *has* to 
vastly reduce it's attack exposure.


It is true that the exposure is reduced, just as it is with a stateful 
firewall. The technical term for this is "security by obscurity". Being 
obscure, however, is not the same as being invisible or being 
protected. It just means that you're a little harder to hit. When a NAT 
sets up an association between an "inside" and "outside" address+port 
pair, that constitutes a bridge between the inside device and the 
outside world. There are ample attacks that are perpetrated through 
that association.


A NAT, in that context, is a stateful firewall that changes the 
addresses, which means that the end station cannot use IPSEC to ensure 
that it is still talking with the same system on the outside. It is 
able to use TLS, SSH, etc as transport layer solutions, but those are 
subject to attacks on TCP such as RST attacks, data insertion, 
acknowledge hacking, and so on, and SSH also has a windowing problem 
(on top of TCP's window, SSH has its own window, and in large 
delay*bandwidth product situations SSH's window is a performance 
limit). In other words, a NAT is a man-in-the-middle attack, or is a 
device that forces the end user to expose himself to man-in-the-middle 
attacks. A true stateful firewall that allows IPSEC end to end doesn't 
expose the user to those attacks.

Re: OMB: IPv6 by June 2008

[Matt Ghali]

On Fri, 8 Jul 2005, Brad Knowles wrote:
  
  >  It's cheap enough, even today. And we have not 1,000,000 routes yet.
  
The please feel free to upgrade the entire Internet, and 
  come back to us when you're done.
  
You keep using the "entire internet" in your replies, when I was 
under the assumption that we were discussing the inter-provider DFZ. 

The only routers which could possibly be affected by the "prefix 
bloat problem" would be multi-homed and mostly inter-provider, which 
is a small fraction of "all routers on the internet".

I'm not trying to accuse you of anything, but your arguments are 
beginning to sound like a disingenuous straw-man.

matto

[EMAIL PROTECTED]<
  The only thing necessary for the triumph
  of evil is for good men to do nothing. - Edmund Burke

Re: mh (RE: OMB: IPv6 by June 2008)

[David Andersen]

On Jul 8, 2005, at 12:49 PM, Jay R. Ashworth wrote:



On Thu, Jul 07, 2005 at 01:31:57PM -0700, Crist Clark wrote:

And if you still want "the protection of NAT," any stateful firewall
will do it.


That seems a common viewpoint.

I believe the very existence of the Ping Of Death rebuts it.

A machine behind a NAT box simply is not visible to the outside world,
except for the protocols you tunnel to it, if any.   This *has* to
vastly reduce it's attack exposure.


Not really.  Consider the logic in a NAT box:

  if (state table entry exists for packet) {
 translate_header();
 send();
  } else {
 drop();
  }

and the logic in a stateful firewall:

  if (state table entry exists for packet) {
 send();
  } else {
 drop();
  }

This is *exactly* the core of what a NAT does, minus the header 
mangling.  The ping of death exposure, for instance, is identical in 
both cases:  The way to ping of death someone is to find a valid state 
table entry and exploit it (e.g., if you could do a PoD in reverse by 
using a too-large ICMP reply, and first convince the victim to ping 
you).


Configuration options can change the behavior of either, e.g., 
configuring an internal host to be the "DMZ" host on a NAT, which 
changes the logic to:


  if (state table) ...
  else
 send_to_dmz_host();

The equivalent operation on a stateful firewall is a permit rule.  A 
stateful firewall can expose more internal hosts to the outside than a 
NAT with only one IP address, simply because it can have more 
addressable space to use (if you've only got one IP address, there's 
only one person who can receive pings).  But in general, the two are 
nearly identical, by virtue of the state table check.


  -Dave

Re: mh (RE: OMB: IPv6 by June 2008)

[Jay R. Ashworth]

On Thu, Jul 07, 2005 at 01:31:57PM -0700, Crist Clark wrote:
> And if you still want "the protection of NAT," any stateful firewall
> will do it.

That seems a common viewpoint.

I believe the very existence of the Ping Of Death rebuts it.

A machine behind a NAT box simply is not visible to the outside world,
except for the protocols you tunnel to it, if any.   This *has* to
vastly reduce it's attack exposure.

Anyone with a pointer to an *in depth* explanation somewhere of why
that assumption is invalid can mail it to me off list, and I'll shut
up.

Cheers,
-- jra
-- 
Jay R. Ashworth[EMAIL PROTECTED]
Designer  Baylink RFC 2100
Ashworth & AssociatesThe Things I Think'87 e24
St Petersburg FL USA  http://baylink.pitas.com +1 727 647 1274

  If you can read this... thank a system administrator.  Or two.  --me

Re: OMB: IPv6 by June 2008

[Scott McGrath]

On the subject of how many entities should be multihomed.   Any entitiy 
whose operations would be significantly impacted by the loss of their 
connectivity to the global internet.


A personal example with names withheld to protect the guilty

A distributor who took 85% of their orders over the internet the rest was 
phone and EDI the telcom coordinator got a 'great deal' on Internet service 
and LD from an unnamed vendor.   Well we cut over our links and within a 
week our major customers had trouble reaching us due to the SP relying only 
on the public peering points to exchange traffic with other networks.


At that point I set up BGP got an AS and reconnected our new provider and 
our old provider so that we had service from both SP's


A 30 year old company almost went out of business due to being single-homed.

Being dependent on a single SP is a "Bad Thing (tm)"

At 04:02 AM 7/8/2005, Alexei Roudnev wrote:


Moreover, if you are not multihomned, you can be aggregated. If you became
multihome - yes, you take a slot; how many entities in the world should be
multihomed?

- Original Message -
From: "Kuhtz, Christian" <[EMAIL PROTECTED]>
To: "David Conrad" <[EMAIL PROTECTED]>; "Alexei Roudnev"
<[EMAIL PROTECTED]>
Cc: "Mohacsi Janos" <[EMAIL PROTECTED]>; "Daniel Golding"
<[EMAIL PROTECTED]>; "Scott McGrath" <[EMAIL PROTECTED]>;

Sent: Thursday, July 07, 2005 11:02 AM
Subject: RE: OMB: IPv6 by June 2008



> Alexei,
>
> On Jul 7, 2005, at 9:58 AM, Alexei Roudnev wrote:
> > What's the problem with independent address space for every entity
> > (company,
> > family, enterprise) which wants it?
>
> It doesn't scale.  Regardless of Moore's law, there are some
> fundamental physical limits that constrain technology.

I would contend that is not true.  What says that every device inside a
company, family, enterprise etc has to be available and reachable by
anyone on the planet in a bidirectional fashion as far as session
initiation is concerned?

Once you add that bit of reality to it, the scaling requirement goes
down substantially.  Wouldn't you agree?

Trust me, I would like to just see us get it over with as far as IPv6 is
concerned, provided we have a working, palatable IPv6 mh solution.  But,
man, I can't pass the red face test on a lot of these hypothesis :(

Thanks,
Christian


The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from all
computers. 163

Re: OMB: IPv6 by June 2008

[Daniel Golding]

Rubbish. Many of the organizations that hold legacy /8s are Universities. If
a .edu can pick up even a few million dollars from selling off a class A,
they will. After all, they could simply sell chunks.

$1 per IP address is the going rate, as I understand - not so much for "grey
market" transactions, but as a valuation used in merger/divestiture
situations.

If we simultaneously start making address space fungible (#nanog vocabulary
word of the day!) and keep giving it away from the RIRs folks will have a
choice. Choice is good.

As some point, as address space becomes scarce, it will become more
valuable. As it becomes more valuable, people will be willing to spend more
money to get addresses. This is basic economics. We have an artificially
scarce (but finite) resource - the market can fix our problems.

At some point, the cost of buying enough address space for a given service
provider or enterprise will become more than the cost of implementing IPv6.
The market will then drive v6 implementation.

Our system of allocating IP addresses is a cross between soviet-style
central planning and FCC spectrum allocation. That doesn't need to occur. We
can morph the RIRs into commodity exchanges and solve the following issues:

- irritation with RIR procedures for getting address space
- justification for address space ("cash is my justification")
- worries about running out of address space as folks sell their hoarded
space and the market loosens
- motivation for shifting to v6 - there will be a real cost to using v4
addresses, but v6 addresses will be free.

We can try to regulate the heck out of this, or let the market handle it. To
quote Gorden Gecko, "greed is good" - at least for driving IPv6 adoption.

- Dan

On 7/8/05 5:27 AM, "Iljitsch van Beijnum" <[EMAIL PROTECTED]> wrote:

> 
> On 8-jul-2005, at 9:42, David Conrad wrote:
> 
> 
>>> There are some 45 - 50 /8s assigned to single organizations. Let's
>>> assume for simplicity that those can all be reclaimed. That's 4
>>> years at a /8 a month. So far so good. Then there are 40 - 45 /8s
>>> in class B space. That means 256 times as much effort to reclaim
>>> the address space, or reclaiming about 10 class Bs a day...
>>> 
> 
> 
>> There is, of course, a slightly different model:
>> 
> 
> 
>> As IPv4 address space becomes less freely available, there will be
>> an increase in black and gray market transactions for that address
>> space.  Since these transactions involve actual money instead of
>> the more difficult to account for human activity dealing with the
>> RIRs or ISPs, there will be financial incentive both to reduce
>> consumption as well as offer allocated but unused space via the
>> black and gray markets.
>> 
> 
> I'm not saying you're wrong (although the RIRs may do their best to
> stop the sale of address space, with unknown success), but I'm not
> sure this will make a huge difference.
> 
> There are currently both holders of big chunks of address space, and
> holders of small chunks of address space, as well as organizations
> that burn up massive amounts of address space and those that use up
> very little. I can easily see how it makes sense for the users of
> relatively small amounts of address space to purchase or lease it
> from holders of (largely) unused /8s. At $1 per address, buying a /24
> rather than jump through RIR hoops is probably a good deal for most
> people, while at $1 per address selling off your /8 is certainly
> worth the trouble.
> 
> However, I don't think the likes of Comcast (which received 3 /10s or
> 3/4 of a /8 this year, or more than $12 million worth at our
> speculated $1/addr) are going to want to spend this kind of money as
> long as there is ANY chance they can get addresses from the RIRs.
> 
> And then, think about it: how much money per address would you have
> to offer to someone with a spare /24 to part from those addresses?
> $1? $5? $10? I doubt the big ISPs that burn millions of addresses per
> year will be interested in that. Suddenly the transition to IPv6 (or
> recursive NAT...) is going to look very attractive.
> 
> So basically the tradeoffs between market forces and regular
> reclaming are similar: easy for /8s, hard for /16s and close to
> impossible for /24s.
> 
> And the real fun starts when people holding big blocks of address
> space start holding on to it because they expect to make more money
> that way in the future...
> 

-- 
Daniel Golding
Network and Telecommunications Strategies
Burton Group

Re: OMB: IPv6 by June 2008

[Brad Knowles]

At 1:59 AM -0700 2005-07-08, Alexei Roudnev wrote:


 You do not need to - any router have only `1 - 10% of all routing table
 active, and it is always possible to optimize these alghoritms.


	If you've got proven solutions to all of the problems raised in 
RFC 3869, section 3.3, I'm sure we'd love to hear about them.  Heck, 
if you've got even just one proven solution to one of those problems, 
we'd love to hear about them.


	But I think you're being more than a little disingenuous if you 
do not have proven solutions and simply roll out "Let's replace all 
the Internet core routers with dirt-cheap PCs" every time someone 
talks about an Internet routing scalability problem.



	Give me some evidence that you truly understand the problems of a 
Tier-1 provider, and that you've got real-world solutions, and I'd be 
perfectly happy to learn from whatever lessons you've got to teach.


	But even I am smart enough to figure out that the "let them eat 
cake" routine isn't particularly useful.


--
Brad Knowles, <[EMAIL PROTECTED]>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755

  SAGE member since 1995.  See  for more info.

Re: OMB: IPv6 by June 2008

[Iljitsch van Beijnum]

On 8-jul-2005, at 9:42, David Conrad wrote:


There are some 45 - 50 /8s assigned to single organizations. Let's  
assume for simplicity that those can all be reclaimed. That's 4  
years at a /8 a month. So far so good. Then there are 40 - 45 /8s  
in class B space. That means 256 times as much effort to reclaim  
the address space, or reclaiming about 10 class Bs a day...






There is, of course, a slightly different model:




As IPv4 address space becomes less freely available, there will be  
an increase in black and gray market transactions for that address  
space.  Since these transactions involve actual money instead of  
the more difficult to account for human activity dealing with the  
RIRs or ISPs, there will be financial incentive both to reduce  
consumption as well as offer allocated but unused space via the  
black and gray markets.




I'm not saying you're wrong (although the RIRs may do their best to  
stop the sale of address space, with unknown success), but I'm not  
sure this will make a huge difference.


There are currently both holders of big chunks of address space, and  
holders of small chunks of address space, as well as organizations  
that burn up massive amounts of address space and those that use up  
very little. I can easily see how it makes sense for the users of  
relatively small amounts of address space to purchase or lease it  
from holders of (largely) unused /8s. At $1 per address, buying a /24  
rather than jump through RIR hoops is probably a good deal for most  
people, while at $1 per address selling off your /8 is certainly  
worth the trouble.


However, I don't think the likes of Comcast (which received 3 /10s or  
3/4 of a /8 this year, or more than $12 million worth at our  
speculated $1/addr) are going to want to spend this kind of money as  
long as there is ANY chance they can get addresses from the RIRs.


And then, think about it: how much money per address would you have  
to offer to someone with a spare /24 to part from those addresses?  
$1? $5? $10? I doubt the big ISPs that burn millions of addresses per  
year will be interested in that. Suddenly the transition to IPv6 (or  
recursive NAT...) is going to look very attractive.


So basically the tradeoffs between market forces and regular  
reclaming are similar: easy for /8s, hard for /16s and close to  
impossible for /24s.


And the real fun starts when people holding big blocks of address  
space start holding on to it because they expect to make more money  
that way in the future...

Re: OMB: IPv6 by June 2008

[Brad Knowles]

At 1:59 AM -0700 2005-07-08, Alexei Roudnev wrote:


 You do not need to - any router have only `1 - 10% of all routing table
 active,


And do you have evidence to back up this claim?


 and it is always possible to optimize these alghoritms.


Please feel free to do so.  Then come back to us when you're done.


 On the other hand - what's wrong with 4Gb on line card in big core router?


	Because most of them aren't capable of supporting that?  Maybe 
only the most expensive line cards which cost tens of thousands of 
dollars for just one card, and you have to have dozens or hundreds of 
such cards for a large Tier-1 network?  Not to mention the hundreds 
of thousands or millions of dollars that you have to spend to get the 
ultra high-end chassis into which the expensive line cards have to be 
plugged in?



 It's cheap enough, even today. And we have not 1,000,000 routes yet.


	The please feel free to upgrade the entire Internet, and come 
back to us when you're done.


--
Brad Knowles, <[EMAIL PROTECTED]>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755

  SAGE member since 1995.  See  for more info.

Re: OMB: IPv6 by June 2008

[Alexei Roudnev]

You do not need to - any router have only `1 - 10% of all routing table
active, and it is always possible to optimize these alghoritms.

On the other hand - what's wrong with 4Gb on line card in big core router?
It's cheap enough, even today. And we have not 1,000,000 routes yet.


- Original Message - 
From: "Brad Knowles" <[EMAIL PROTECTED]>
To: "NANOG" 
Sent: Friday, July 08, 2005 1:03 AM
Subject: Re: OMB: IPv6 by June 2008


>
> At 12:51 AM -0700 2005-07-08, Alexei Roudnev wrote:
>
> >  Who need this complexity?  What's wrong with old good _routing rotocol_
> >  approach? Memory? (do not joke, today 4 Gb RAM is not a problem, when
it is
> >  for slow routing system). CPU (the same)? What else?
>
> Can you put 4GB on every linecard on every router you own?  Can
> you put a Power5 or PowerPC 970MP processor on every linecard on
> every router you own?  Does your vendor support you making any
> modifications/upgrades to any of their linecards, or do they require
> you to buy new ones with the go-faster features?
>
> And how many tens of thousands of dollars do each of those
> go-faster linecards cost?  And how many million-dollar fork-lift
> upgrades do you have to pay for in order to get the go-faster chassis
> in which to plug those go-faster cards into?
>
> Do you have thousands of routers?  Hundreds of thousands?
>
>
> I'm asking serious questions here.  I'm not a router guy, but
> I've heard a lot of comments on this list that give me pause, so I'd
> like to get real-world answers.
>
>
> Speaking from my own perspective, it seems to me that we've got a
> scalability problem here when we're expecting most devices to have a
> pretty complete picture of the entire world.  I think that's the real
> problem that has to be addressed.
>
> In terms of the routing protocols and number of ASes, we know
> that it's possible to build machines which can handle those kinds of
> things at those kinds of numbers.  The problem is that it's hard to
> do those kinds of things on a widespread basis (e.g., in every
> linecard in every router in the world), and most devices probably
> don't need that anyway.
>
> I don't know what the real solution is.  But it seems to me that
> we need to find something, and having people say "4GB of RAM?  No
> problem" is not the way to get this solved.
>
> -- 
> Brad Knowles, <[EMAIL PROTECTED]>
>
> "Those who would give up essential Liberty, to purchase a little
> temporary Safety, deserve neither Liberty nor Safety."
>
>  -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
>  Assembly to the Governor, November 11, 1755
>
>SAGE member since 1995.  See <http://www.sage.org/> for more info.

Re: OMB: IPv6 by June 2008

[Brad Knowles]

At 1:11 AM -0700 2005-07-08, Alexei Roudnev wrote:


 What is CPU power of today's core routers? What's memory? Compare with
 junk-yard server - 2 x 1.4Ggz CPU, 4 GB RAM, total price about $1.5K.


	Fair enough.  Since they're trivially cheap, you get to pay for 
upgrading all the routers in the world.  Come back to us when you're 
done.


--
Brad Knowles, <[EMAIL PROTECTED]>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755

  SAGE member since 1995.  See  for more info.

Re: OMB: IPv6 by June 2008

[Randy Bush]

> What is CPU power of today's core routers? What's memory? Compare with
> junk-yard server - 2 x 1.4Ggz CPU, 4 GB RAM, total price about $1.5K.
> 
> Routers have 3 - 10 times reserve _today_ . Then, you can always sacrify
> reaction time a little. Reserves are tremendous in this area.
> 
>>> Is it a pproblem keeping 500,000 routess in core routers? Of
>>> course, it is not (it was in 1996, but it is not in 2005
>>
>> really?  we have not seen this so how do you know?  and it
>> will be fine with churn and pushing 300k forwarding entries
>> into the fibs on a well-known vendor's line cards?

clue: some large isps have routers falling over today due to
  ram limitations on line cards.  and it will cost a LOT
  of money for them to do upgrades which will last not
  long enough.

as this is an ops list, can we try to stay somewhere in the
neighborhood of operational realities?

randy

Re: OMB: IPv6 by June 2008

[Alexei Roudnev]

Moreover, if you are not multihomned, you can be aggregated. If you became
multihome - yes, you take a slot; how many entities in the world should be
multihomed?

- Original Message - 
From: "Kuhtz, Christian" <[EMAIL PROTECTED]>
To: "David Conrad" <[EMAIL PROTECTED]>; "Alexei Roudnev"
<[EMAIL PROTECTED]>
Cc: "Mohacsi Janos" <[EMAIL PROTECTED]>; "Daniel Golding"
<[EMAIL PROTECTED]>; "Scott McGrath" <[EMAIL PROTECTED]>;

Sent: Thursday, July 07, 2005 11:02 AM
Subject: RE: OMB: IPv6 by June 2008



> Alexei,
>
> On Jul 7, 2005, at 9:58 AM, Alexei Roudnev wrote:
> > What's the problem with independent address space for every entity
> > (company,
> > family, enterprise) which wants it?
>
> It doesn't scale.  Regardless of Moore's law, there are some
> fundamental physical limits that constrain technology.

I would contend that is not true.  What says that every device inside a
company, family, enterprise etc has to be available and reachable by
anyone on the planet in a bidirectional fashion as far as session
initiation is concerned?

Once you add that bit of reality to it, the scaling requirement goes
down substantially.  Wouldn't you agree?

Trust me, I would like to just see us get it over with as far as IPv6 is
concerned, provided we have a working, palatable IPv6 mh solution.  But,
man, I can't pass the red face test on a lot of these hypothesis :(

Thanks,
Christian


The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from all
computers. 163

Re: OMB: IPv6 by June 2008

[Alexei Roudnev]

What is CPU power of today's core routers? What's memory? Compare with
junk-yard server - 2 x 1.4Ggz CPU, 4 GB RAM, total price about $1.5K.

Routers have 3 - 10 times reserve _today_ . Then, you can always sacrify
reaction time a little. Reserves are tremendous in this area.

- Original Message - 
From: "Randy Bush" <[EMAIL PROTECTED]>
To: "Alexei Roudnev" <[EMAIL PROTECTED]>
Cc: 
Sent: Thursday, July 07, 2005 1:23 PM
Subject: Re: OMB: IPv6 by June 2008


> > Is it a pproblem keeping 500,000 routess in core routers? Of
> > course, it is not (it was in 1996, but it is not in 2005
>
> really?  we have not seen this so how do you know?  and it
> will be fine with churn and pushing 300k forwarding entries
> into the fibs on a well-known vendor's line cards?
>
> randy
>

Re: OMB: IPv6 by June 2008

[Mikael Abrahamsson]

On Fri, 8 Jul 2005, Alexei Roudnev wrote:

Who need this complexity?  What's wrong with old good _routing rotocol_ 
approach? Memory? (do not joke, today 4 Gb RAM is not a problem, when it 
is for slow routing system). CPU (the same)? What else?


TCAMs are expensive and complex.

Convergence time is also a problem.

--
Mikael Abrahamssonemail: [EMAIL PROTECTED]

Re: OMB: IPv6 by June 2008

[Brad Knowles]

At 12:51 AM -0700 2005-07-08, Alexei Roudnev wrote:


 Who need this complexity?  What's wrong with old good _routing rotocol_
 approach? Memory? (do not joke, today 4 Gb RAM is not a problem, when it is
 for slow routing system). CPU (the same)? What else?


	Can you put 4GB on every linecard on every router you own?  Can 
you put a Power5 or PowerPC 970MP processor on every linecard on 
every router you own?  Does your vendor support you making any 
modifications/upgrades to any of their linecards, or do they require 
you to buy new ones with the go-faster features?


	And how many tens of thousands of dollars do each of those 
go-faster linecards cost?  And how many million-dollar fork-lift 
upgrades do you have to pay for in order to get the go-faster chassis 
in which to plug those go-faster cards into?


Do you have thousands of routers?  Hundreds of thousands?


	I'm asking serious questions here.  I'm not a router guy, but 
I've heard a lot of comments on this list that give me pause, so I'd 
like to get real-world answers.



	Speaking from my own perspective, it seems to me that we've got a 
scalability problem here when we're expecting most devices to have a 
pretty complete picture of the entire world.  I think that's the real 
problem that has to be addressed.


	In terms of the routing protocols and number of ASes, we know 
that it's possible to build machines which can handle those kinds of 
things at those kinds of numbers.  The problem is that it's hard to 
do those kinds of things on a widespread basis (e.g., in every 
linecard in every router in the world), and most devices probably 
don't need that anyway.


	I don't know what the real solution is.  But it seems to me that 
we need to find something, and having people say "4GB of RAM?  No 
problem" is not the way to get this solved.


--
Brad Knowles, <[EMAIL PROTECTED]>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755

  SAGE member since 1995.  See  for more info.

Re: OMB: IPv6 by June 2008

[Alexei Roudnev]

Who need this complexity?  What's wrong with old good _routing rotocol_
approach? Memory? (do not joke, today 4 Gb RAM is not a problem, when it is
for slow routing system). CPU (the same)? What else?

If it looked as a problem 10 years ago, it can not be relevant to today's
realities.

- Original Message - 
From: "Joe Abley" <[EMAIL PROTECTED]>
To: "Andre Oppermann" <[EMAIL PROTECTED]>
Cc: "NANOG list" ; "Alexei Roudnev" <[EMAIL PROTECTED]>;
"Iljitsch van Beijnum" <[EMAIL PROTECTED]>
Sent: Thursday, July 07, 2005 8:11 AM
Subject: Re: OMB: IPv6 by June 2008


>
> On 2005-07-07, at 10:23, Andre Oppermann wrote:
>
> > It was about a spot in the global routing table.  No matter if one
> > gets
> > PA or PI they get a routing table entry in the DFZ.  There is no
> > way around
> > it other than to make the routing protocols more scaleable.
>
> With the hole-punching/CIDR abuse multihoming that is widely used in
> IPv4, a slot in the DFZ gets burned each time an end site adds a
> provider, regardless of whether they are using PA or PI addresses.
> This slot represents state information for the multi-homed site which
> answers the question "how else can this set of addresses be reached?"
>
> The shim6 approach shifts this state from the DFZ to the endpoints
> which are exchanging unicast traffic. The endpoints exchange a set of
> possible locators through a protocol element within the IP layer and
> handle locator migration transparently to the transport layer above.
> Hence the question "how else can this particular remote address be
> reached" is answered using information on the host, not information
> in the network.
>
> With shim6 an end site can multi-home using one PA prefix per
> provider, without taking up additional slots in the DFZ. Hosts within
> the site are given multiple addresses (locators), and the layer-3
> shim handles any change of locator needed for traffic exchanged
> between any two hosts.
>
> If one (or both) of the hosts exchanging traffic don't support shim6,
> then the traffic is exchanged without transport-layer stability
> across re-homing events (and, potentially, without any optimisation
> as to the choice of endpoint addresses for the session).
>
> So, the shim6 future of multihoming looks like this:
>
> 1. ISPs multi-home exactly as people are used to doing today, using
> PI prefixes, and taking up a slot in the DFZ per transit provider.
> Everybody is familiar with this already. There is no change for ISPs
> in this picture.
>
> 2. Multi-homed end sites obtain one PA prefix per upstream ISP, and
> hosts within those end-sites are assigned multiple addresses (in some
> automated, secure and controllable fashion). There are no additional
> slots burned in the DFZ by end site multi-homing. Hosts obtain
> transport-layer reliability across re-homing events using shim6,
> rather than relying on the network to take care of it.
>
>
> Joe

Re: OMB: IPv6 by June 2008

[David Conrad]

On Jul 7, 2005, at 2:14 PM, Iljitsch van Beijnum wrote:
Right again. And like prospecting for oil, at some point you're  
burning it up faster than you can prospect it.


There are some 45 - 50 /8s assigned to single organizations. Let's  
assume for simplicity that those can all be reclaimed. That's 4  
years at a /8 a month. So far so good. Then there are 40 - 45 /8s  
in class B space. That means 256 times as much effort to reclaim  
the address space, or reclaiming about 10 class Bs a day...


There is, of course, a slightly different model:

As IPv4 address space becomes less freely available, there will be an  
increase in black and gray market transactions for that address  
space.  Since these transactions involve actual money instead of the  
more difficult to account for human activity dealing with the RIRs or  
ISPs, there will be financial incentive both to reduce consumption as  
well as offer allocated but unused space via the black and gray markets.


In this model, you get a natural, market-driven evolution towards a  
two tiered routing hierarchy (call it "the core" and "the edge")  
mediated by That Which Shall Not Be Named.  As folks who "own"  
address space (yes, I know, address space isn't "owned".  I suspect  
this convention might break down pretty quickly as address space  
becomes more scarce) figure out there's gold in dem dar unused tracts  
of address space, they'll make a quick buck selling it to somebody  
who desires it more (as demonstrated by their willingness to pay the  
"owner's" price) and moving their infrastructure behind a TWSNBN.   
Large blocks and provider aggregateable space will command a higher  
price, long prefix blobs spread out randomly a lower price due to the  
pain of trying to get it routed.


Imagine (to pick an example purely at random) the President of MIT  
being presented with the choice of receiving a very large wad of cash  
in exchange for 18/8.  How big would that wad have to be before she  
decided it'd be worth migrating 18/8 to 10/8 and living behind a TWSNBN?


Of course, I'm sure this is all just a feverish nightmare caused by a  
bad habanero pepper...  (why do I get a recurring image of Peter  
Lothberg wandering around the room collecting all the little balls he  
can?).


Rgds,
-drc

P.S. No, I am not suggesting this is a good or even a likely  
outcome.  Just pointing out that there can be other forces coming  
into play as scarcity becomes more noticeable.

Re: OMB: IPv6 by June 2008

[Nils Ketelsen]

Jeroen Massar wrote:

> 
>>2 - Replace network elements with IPv6 compatible network elements and S/W
> 
> On a per-link basis, start with tunnels where needed, go native later on
> or rather directly when possible. Most Cisco's can be upgraded to
> support IPv6, JunOS supports it too, though they now suddenly require
> some absurd fee especially for IPv6. For most layer2 setups getting IPv6
> working is really a matter of upgrading the kernels or just enabling it.

The problem are printers, thermometers, cameras, barcodescanners or in
case of the person you are replying to: strange scientific instruments
(I guess).


Nils

Re: OMB: IPv6 by June 2008

[Petri Helenius]

Randy Bush wrote:


Is it a pproblem keeping 500,000 routess in core routers? Of
course, it is not (it was in 1996, but it is not in 2005
   



really?  we have not seen this so how do you know?  and it
will be fine with churn and pushing 300k forwarding entries
into the fibs on a well-known vendor's line cards?

 

Soon the fib can be replaced by just an array with an index for every 
IPv4 address. With <255 interfaces, 4G is sufficient .-)


Pete

Re: OMB: IPv6 by June 2008

[James]

On Thu, Jul 07, 2005 at 02:55:08PM -0400, Scott McGrath wrote:
> 
> 
> On the training issue.  Everybody in our organization understands IPv4 at
> some basic level.  The senior staff here myself included are conversant
> with IPv6 but you have the level 1 and 2 people who for the most part are
> not even aware IPv6 exists and there are a LOT more of them then there are
> of us and these are the people who are going to get their world rocked and
> who will need extensive training to be effective in a IPv6 world.

May be my view is quite limited.  But just what exactly is soo hard about
IPv6 other than hexadecimal and /128 space?  Forget the NLA, TLA jazz, they
are all deprecated as of RFC3587.  CIDR at 128 bits and hex.. doesn't sound
too complicated to me for any average networker dealing with IP subnetting.

Most people who seem to have extensive trouble with IPv6 in my experience
happen to have trouble doing CIDR subnetting in IPv4 as well..  But for
average first-tier support, they just need to hear what IP6 addresses are
being involved, and using regular network troubleshooting tools like they
have been in IPv4.  I don't see much issue with this other than theoratical
nightmares thought due to the hexadecimal look.

With regards to your comment about multihoming, your concerns are certainly
valid and this goes back to the whole "The Great IPv6 Multihoming Debate."
Until it is resolved, some people are currently asking their upstreams to
pass their PA space to their peers just like the way it is in IPv4.  We
currently do this for couple of downstreams who are multihomed but unable
to justify for a /32 PI space at the time.  As long as you get two larger
v6 networks to pass along your PA space, you should be able to reach most
popular v6 contents using multihomed path.

I have a feeling, sooner or later, either scalable solution which can be
implemented will be introduced, or customers will simply ask their uplinks
to announce them or threaten to cancel service, just like in IPv4 world.

James


-- 
James Jun
Infrastructure and Technology Services
TowardEX Technologies
Office +1-617-459-4051 x179 | Mobile +1-978-394-2867
[EMAIL PROTECTED] | www.towardex.com

Re: OMB: IPv6 by June 2008

[Iljitsch van Beijnum]

On 7-jul-2005, at 22:03, Jay R. Ashworth wrote:


   Are there
hidden pockets of yet undiscovered address space?



Undiscovered?  No.



But unless the situation has changed since I last looked (which is
possible), there are some sizeable clumps that will never get used by
the people who "own" them, which it has not been practicable to
reclaim.


Right.


The tighter the vise, the higher the fence it will be worthwhile to
jump to reclaim that space... just like prospecting for oil.


Right again. And like prospecting for oil, at some point you're  
burning it up faster than you can prospect it.


There are some 45 - 50 /8s assigned to single organizations. Let's  
assume for simplicity that those can all be reclaimed. That's 4 years  
at a /8 a month. So far so good. Then there are 40 - 45 /8s in class  
B space. That means 256 times as much effort to reclaim the address  
space, or reclaiming about 10 class Bs a day...


Predicting is hard, especially when it concerns the future. But one  
thing is certain: we live in interesting times.

Re: OMB: IPv6 by June 2008

[Randy Bush]

> a) I suspect most SSL implementations derive out of the same code base.

definitely not!  at least three major ones out there.

randy

Re: mh (RE: OMB: IPv6 by June 2008)

[Crist Clark]

Petri Helenius wrote:

Crist Clark wrote:



And the counter point to that argument is that the sparse population
of IPv6 space will make systematic scanning by worms an ineffective
means of propagation.



Any by connecting to one of the p2p overlay networks you'll have a few 
million in-use addresses momentarily.


Preventing abuse of information available from databases maintained
by P2P services is an emerging and interesting area of info sec. It may
become more so as other means of harvesting "live" addresses become
less productive. In The Future, the addresses of live hosts to attack
may become an underworld commodity like valid email addresses are now.
All of those are better than having Blaster or Slammer propagate so
easily. At least make the malware authors work for it.

If you were behind NAT, you couldn't use those P2P applications. So, yeah,
you were safe on your limited-functionality, pseudo-IP, NATed connection
from the Big Bad P2P.

And if you still want "the protection of NAT," any stateful firewall
will do it.

IMHO, if there is any reason NAT will live on in IPv6 it is the PI space
issue. Even the NAP draft comes out and says,

  4.7  Multihoming and renumbering

 Multihoming and renumbering remain technically challenging with IPv6...

That plus the problems with the unique local proposals make it quite
likely that NAT will not completely disappear should IPv6 become
widespread.
--
Crist J. Clark   [EMAIL PROTECTED]
Globalstar Communications(408) 933-4387

Re: OMB: IPv6 by June 2008

[Randy Bush]

> Is it a pproblem keeping 500,000 routess in core routers? Of
> course, it is not (it was in 1996, but it is not in 2005

really?  we have not seen this so how do you know?  and it
will be fine with churn and pushing 300k forwarding entries
into the fibs on a well-known vendor's line cards?

randy

RE: OMB: IPv6 by June 2008

[Brad Knowles]

At 1:02 PM -0500 2005-07-07, Kuhtz, Christian wrote:


 It doesn't scale.  Regardless of Moore's law, there are some
 fundamental physical limits that constrain technology.


 I would contend that is not true.  What says that every device inside a
 company, family, enterprise etc has to be available and reachable by
 anyone on the planet in a bidirectional fashion as far as session
 initiation is concerned?


	The problem is that you don't know, a priori, which devices will 
or will not need to be fully externally addressable.  Even if we talk 
about just mobile phones, it's easy to imagine billions of devices 
world-wide that will need connectivity in the near future.



	Most devices won't need full bidirectional connectivity all the 
time, no.  But it's also easy to imagine circumstances where you 
decide that you need to change the setting on the VCR or check the 
stove to see if you forgot and left it turned on.


	If you can give all the devices in your home full bidirectional 
connectivity (via a secure method, of course), then a whole lot of 
options open up that would otherwise not have been possible.


--
Brad Knowles, <[EMAIL PROTECTED]>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755

  SAGE member since 1995.  See  for more info.

Re: mh (RE: OMB: IPv6 by June 2008)

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, "Tony Hain" writes:
>
>Mangling the header did not prevent the worms, lack of state did that. A
>stateful filter that doesn't need to mangle the packet header is frequently
>called a firewall (yes some firewalls still do, but that is by choice). 
>

Absolutely correct.  Real firewalls pass inbound traffic because a 
state table entry exists.  NATs do the same thing, with nasty 
side-effects.  There is no added security from the header-mangling.

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

Re: OMB: IPv6 by June 2008

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, David Conrad wri
tes:
>
>Christian,
>
>On Jul 7, 2005, at 11:02 AM, Kuhtz, Christian wrote:
 What's the problem with independent address space for every entity
 (company, family, enterprise) which wants it?
>>> It doesn't scale.  Regardless of Moore's law, there are some
>>> fundamental physical limits that constrain technology.
>> Once you add that bit of reality to it, the scaling requirement goes
>> down substantially.  Wouldn't you agree?
>
>My feeling is that the question isn't how much memory, but rather how  
>much CPU and bandwidth is necessary to deal with routing thrash.   

That's right.  The issues are the complexity of the routing computation 
and the convergence time/stability of the routing computation as a 
whole.

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

Re: mh (RE: OMB: IPv6 by June 2008)

[Petri Helenius]

Crist Clark wrote:



And the counter point to that argument is that the sparse population
of IPv6 space will make systematic scanning by worms an ineffective
means of propagation.


Any by connecting to one of the p2p overlay networks you'll have a few 
million in-use addresses momentarily.


Pete

Re: OMB: IPv6 by June 2008

[Jay R. Ashworth]

On Wed, Jul 06, 2005 at 09:46:53PM +0200, Iljitsch van Beijnum wrote:
> We know how many IPv4 addresses there are. We know how many are  
> unusable (although this number isn't 100% fixed). We know how many  
> were given out. We know how many are given out now each year. What  
> kind of magic do you expect will make this problem that's coming go  
> away?
>Are there  
> hidden pockets of yet undiscovered address space? 

Undiscovered?  No.

But unless the situation has changed since I last looked (which is
possible), there are some sizeable clumps that will never get used by
the people who "own" them, which it has not been practicable to
reclaim.

The tighter the vise, the higher the fence it will be worthwhile to
jump to reclaim that space... just like prospecting for oil.

Cheers,
-- jra
-- 
Jay R. Ashworth[EMAIL PROTECTED]
Designer+-Internetworking--+--+   RFC 2100
Ashworth & Associates   |  Best Practices Wiki |  |'87 e24
St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274

  If you can read this... thank a system administrator.  Or two.  --me

RE: mh (RE: OMB: IPv6 by June 2008)

[Tony Hain]

Mangling the header did not prevent the worms, lack of state did that. A
stateful filter that doesn't need to mangle the packet header is frequently
called a firewall (yes some firewalls still do, but that is by choice). 

Tony 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Andre Oppermann
> Sent: Friday, July 08, 2005 4:42 AM
> To: Fergie (Paul Ferguson)
> Cc: [EMAIL PROTECTED]; nanog@merit.edu
> Subject: Re: mh (RE: OMB: IPv6 by June 2008)
> 
> 
> Fergie (Paul Ferguson) wrote:
>  >
> > I'd have to counter with "the assumption that NATs are going
> > away with v6 is a rather risky assumption." Or perhaps I
> > misunderstood your point...
> 
> There is one thing often overlooked with regard to NAT.  That is,
> it has prevented many network based worms for millions of home
> users behind NAT devices.  Unfortunatly this fact is overlooked
> all the time.  NAT has its downsides but also upsides sometimes.
> 
> --
> Andre

RE: OMB: IPv6 by June 2008

[Kuhtz, Christian]

> My feeling is that the question isn't how much memory, but 
> rather how  
> much CPU and bandwidth is necessary to deal with routing thrash.   

Sure.  Resources in the end.

> Yes, you can aggregate different things to try to reduce the number  
> of entries, but that would seem to go against the general 
> idea Alexei  
> was suggesting.  I mean, I'm an entity, and it'd be cool to have my  
> own routed PI address and not have to deal with reconfiguring my  
> network when I took my laptop from work to home...

Sure.  But, you think the majority of employers feel warm and fuzzy
about this...?  I would say the answer is a violent "hell no"...   Most
security folks get moderately freaked out by people moving machines back
and forth, let alone IP addresses.


*
The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential, proprietary, and/or privileged 
material. Any review, retransmission, dissemination or other use of, or taking 
of any action in reliance upon this information by persons or entities other 
than the intended recipient is prohibited. If you received this in error, 
please contact the sender and delete the material from all computers. 162

Re: mh (RE: OMB: IPv6 by June 2008)

[David Andersen]

On Jul 7, 2005, at 3:41 PM, Andre Oppermann wrote:



Fergie (Paul Ferguson) wrote:
>

I'd have to counter with "the assumption that NATs are going
away with v6 is a rather risky assumption." Or perhaps I
misunderstood your point...


There is one thing often overlooked with regard to NAT.  That is,
it has prevented many network based worms for millions of home
users behind NAT devices.  Unfortunatly this fact is overlooked
all the time.  NAT has its downsides but also upsides sometimes.


Yes, but keep in mind that this benefit is completely unrelated to 
NAT's purpose as an address space extender.  A stateful firewall with a 
very simple rule (permit anything originated from the inside, deny 
anything from outside except a few pesky protocols) would accomplish 
exactly the same goal.


And it would be much easier to punch holes through when you needed to.

From my perspective, the biggest benefit from home NAT devices is that 
they were a vehicle for delivering such a firewall to millions of 
windows boxes.  Unfortunately, this drug comes with a number of harmful 
side effects, including nausea, blurred vision, and the inability to 
deploy a number of new protocols.


  -Dave

Re: mh (RE: OMB: IPv6 by June 2008)

[Crist Clark]

Andre Oppermann wrote:


Fergie (Paul Ferguson) wrote:
 >


I'd have to counter with "the assumption that NATs are going
away with v6 is a rather risky assumption." Or perhaps I
misunderstood your point...



There is one thing often overlooked with regard to NAT.  That is,
it has prevented many network based worms for millions of home
users behind NAT devices.  Unfortunatly this fact is overlooked
all the time.  NAT has its downsides but also upsides sometimes.


And the counter point to that argument is that the sparse population
of IPv6 space will make systematic scanning by worms an ineffective
means of propagation.
--
Crist J. Clark   [EMAIL PROTECTED]
Globalstar Communications(408) 933-4387

RE: mh (RE: OMB: IPv6 by June 2008)

[Tony Hain]

Given that shim breaks fundamental assumptions about the stable relationship
between the packet header and the application context, there will be many
security related issues to be resolved after the shim spec stabilizes. Shim
is a 'more than a decade' effort if it ever completes. 

The disappearance of NAT is not as bad as the FUD that keeps coming up. See:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-01.txt
and please send comments if some use of NAT is not covered. 

As far as alternatives for multi-homing, the IESG has focused on shim and
denied a request for a bof in August to discuss interim options. 

I submitted updates to the ID editor early last month but for some reason
they have not popped out yet, but I am always accepting comments on:
http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-08.txt
http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-use-08.txt
Like the approach or not, it is straight up existing BGP and existing host
stacks. It will never be the highly optimized 400 entry routing table, but
it doesn't pretend to be. It does however create PI space that has some hope
of aggregating.

Tony


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Dave Crocker
> Sent: Friday, July 08, 2005 4:12 AM
> To: Kuhtz, Christian
> Cc: Joe Abley; NANOG list
> Subject: Re: mh (RE: OMB: IPv6 by June 2008)
> 
> 
> 
> 
> > Thanks, I'm fully aware of where shim6 is right now.   I'm asking if
> > anyone feels this is headed anywhere useful or if we got anything else
> > we can use to facilitate mh.
> 
> a shim layer seems like a promising enhancement.  ietf-shim6 is taking an
> approach to a shim layer that will, I suspect, take some time to mature.
> I'd
> be surprised if it saw significant deployment anytime within the next 5
> years,
> at the earliest.
> 
> (a more ascerbic view would probably suggest that it is not even likely to
> produce a complete specification within that time, with deployment taking
> another 5 years...)
> 
> the effort is relying on IPv6 and on the disappearance of NATs, for v6.
> one
> might consider these to be critical dependencies that are rather risky.
> 
> --
> 
>d/
> 
>   Dave Crocker
>   Brandenburg InternetWorking
>   +1.408.246.8253
>   dcrocker  a t ...
>   WE'VE MOVED to:  www.bbiw.net

Re: mh (RE: OMB: IPv6 by June 2008)

[Dave Crocker]

>  I'd have to counter with "the assumption that NATs are going
>  away with v6 is a rather risky assumption." Or perhaps I
>  misunderstood your point...

i think we are agreeing.

i think that any prediction that users will not use nats for v6 involves logic
that can, at best, be called idealistic.  naive would be another term to
consider.


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Re: mh (RE: OMB: IPv6 by June 2008)

[Andre Oppermann]

Fergie (Paul Ferguson) wrote:
>

I'd have to counter with "the assumption that NATs are going
away with v6 is a rather risky assumption." Or perhaps I
misunderstood your point...


There is one thing often overlooked with regard to NAT.  That is,
it has prevented many network based worms for millions of home
users behind NAT devices.  Unfortunatly this fact is overlooked
all the time.  NAT has its downsides but also upsides sometimes.

--
Andre

Re: OMB: IPv6 by June 2008

[David Conrad]

Christian,

On Jul 7, 2005, at 11:02 AM, Kuhtz, Christian wrote:

What's the problem with independent address space for every entity
(company, family, enterprise) which wants it?

It doesn't scale.  Regardless of Moore's law, there are some
fundamental physical limits that constrain technology.

Once you add that bit of reality to it, the scaling requirement goes
down substantially.  Wouldn't you agree?


My feeling is that the question isn't how much memory, but rather how  
much CPU and bandwidth is necessary to deal with routing thrash.   
Yes, you can aggregate different things to try to reduce the number  
of entries, but that would seem to go against the general idea Alexei  
was suggesting.  I mean, I'm an entity, and it'd be cool to have my  
own routed PI address and not have to deal with reconfiguring my  
network when I took my laptop from work to home...


Rgds,
-drc

Re: mh (RE: OMB: IPv6 by June 2008)

[Fergie (Paul Ferguson)]

Dave,

I'd have to counter with "the assumption that NATs are going
away with v6 is a rather risky assumption." Or perhaps I
misunderstood your point...

$.02,

- ferg


-- Dave Crocker <[EMAIL PROTECTED]> wrote:

[re: shim6]

the effort is relying on IPv6 and on the disappearance of NATs, for v6.  one 
might consider these to be critical dependencies that are rather risky.


--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 [EMAIL PROTECTED] or [EMAIL PROTECTED]
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: mh (RE: OMB: IPv6 by June 2008)

[Dave Crocker]

Thanks, I'm fully aware of where shim6 is right now.   I'm asking if
anyone feels this is headed anywhere useful or if we got anything else
we can use to facilitate mh.  


a shim layer seems like a promising enhancement.  ietf-shim6 is taking an 
approach to a shim layer that will, I suspect, take some time to mature.  I'd 
be surprised if it saw significant deployment anytime within the next 5 years, 
at the earliest.


(a more ascerbic view would probably suggest that it is not even likely to 
produce a complete specification within that time, with deployment taking 
another 5 years...)


the effort is relying on IPv6 and on the disappearance of NATs, for v6.  one 
might consider these to be critical dependencies that are rather risky.


--

  d/

 Dave Crocker
 Brandenburg InternetWorking
 +1.408.246.8253
 dcrocker  a t ...
 WE'VE MOVED to:  www.bbiw.net

Re: OMB: IPv6 by June 2008

[Andre Oppermann]

Kuhtz, Christian wrote:

On Jul 7, 2005, at 9:58 AM, Alexei Roudnev wrote:


What's the problem with independent address space for every entity
(company,
family, enterprise) which wants it?


It doesn't scale.  Regardless of Moore's law, there are some
fundamental physical limits that constrain technology.


I would contend that is not true.  What says that every device inside a
company, family, enterprise etc has to be available and reachable by
anyone on the planet in a bidirectional fashion as far as session
initiation is concerned?


Wasn't that the point of IP-Mobility?  Take your one-and-only IP address
anywhere you go?

--
Andre

Re: OMB: IPv6 by June 2008

[Scott McGrath]

On the training issue.  Everybody in our organization understands IPv4 at
some basic level.  The senior staff here myself included are conversant
with IPv6 but you have the level 1 and 2 people who for the most part are
not even aware IPv6 exists and there are a LOT more of them then there are
of us and these are the people who are going to get their world rocked and
who will need extensive training to be effective in a IPv6 world.

Scott C. McGrath

On Thu, 7 Jul 2005, Jeroen Massar wrote:

> On Thu, 2005-07-07 at 18:02 +0200, Andre Oppermann wrote:
> > Jeroen Massar wrote:
> > > On Thu, 2005-07-07 at 10:39 -0400, Scott McGrath wrote:
> > >>4 - Retrain entire staff to support IPv6
> > >
> > > You have to train people to drive a car, to program a new VCR etc. What
> > > is so odd about this?
> >
> > I had training to drive a car once in my life when I got my drivers
> > license.  I don't have to get a fresh training for every new car I
> > end up driving throughout my life.
>
> You will have to get an additional license for driving a truck or even
> when you are getting a caravan behind that car of yours though.
> Motorbikes also have different licenses and you get separate trainings
> for those. They all have wheels, look the same, operate somewhat the
> same, but are just a little bit different and need a bit different
> education.
>
> You also either read something, educated yourself or even got a training
> to operate IPv4 networks, now you will just need a refresh for IPv6.
> You can opt to not take it, but then don't complain you don't understand
> it. For that matter if you don't understand IPv6 you most likely don't
> IPv4 (fully) either.
>
> > If I need training to program my new VCR then the operating mode of
> > that VCR is broken and I'm going to return it asap.
>
> Then a lot of VCR's will be returned because if there is one thing many
> people don't seem to understand, even after reading the manual then it
> is a VCR.
>
> > It's that simple.  Why are people buying iPod's like crazy?  Because
> > these thingies don't require training.  People intuitively can use
> > them because the GUI is designed well.
>
> So you didn't read the manual of or train yourself to use your compiler|
> bgp|isis|rip|operatingsystem| and a lot of other things ?
>
> IP networks are not meant for the general public, they only care that
> the apps that use it work, they don't type on routers.
> Protocols don't have GUI's or do you have a point and click BGP? :)
>
> Greets,
>  Jeroen
>
>

Re: OMB: IPv6 by June 2008

[Iljitsch van Beijnum]

On 7-jul-2005, at 19:43, Kuhtz, Christian wrote:


If I'm on the same shared medium as you I can kill your SSL session
with one packet.



Only if shared medium = vanilla CSMA/CD Ethernet or the like.


Or air.

If the medium isn't shared then if it's a thin pipe, it's subject to  
DoS (I mean the type where you don't even need a zombie army) and if  
it's a fat one, an attacker still gets to break the TCP sessions with  
SSL running over them. (This requires a few million packets.)

Re: OMB: IPv6 by June 2008

[Eric Rescorla]

I don't want to get into an SSL vs. IPsec argument, but...

David Conrad <[EMAIL PROTECTED]> writes:
>> Compare with SSL (works out-of-the-box in 99.999% cases,
>> and allows both, full and hard security with root certificates etc, or
>> simple security based on _ok, I trust you first time, then we can
>> work_.
>
> a) I suspect most SSL implementations derive out of the same code base.

I'd be surprised if this is correct. The three major SSL/TLS 
implementations by deployment are:

1. OpenSSL (used in Apache2, ApacheSSL, and mod_ssl)
2. Microsoft (used in IE and IIS)
3. Firefox/Mozilla (based on Netscape's NSS).

These are all genetically distinct. In addition, there are at least
three independent Java implementations (JSSE, PureTLS, SSLava).
In addition, Terisa Systems (now Spyrus) independently implemented
SSLv3 (though our v2 stack had some of Netscape's SSLref stack)
and I believe that Consensus development did so as well.

-Ekr

RE: OMB: IPv6 by June 2008

[Kuhtz, Christian]

> Alexei,
> 
> On Jul 7, 2005, at 9:58 AM, Alexei Roudnev wrote:
> > What's the problem with independent address space for every entity
> > (company,
> > family, enterprise) which wants it?
> 
> It doesn't scale.  Regardless of Moore's law, there are some
> fundamental physical limits that constrain technology.

I would contend that is not true.  What says that every device inside a
company, family, enterprise etc has to be available and reachable by
anyone on the planet in a bidirectional fashion as far as session
initiation is concerned?

Once you add that bit of reality to it, the scaling requirement goes
down substantially.  Wouldn't you agree?

Trust me, I would like to just see us get it over with as far as IPv6 is
concerned, provided we have a working, palatable IPv6 mh solution.  But,
man, I can't pass the red face test on a lot of these hypothesis :(

Thanks,
Christian


The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential, proprietary, and/or privileged 
material. Any review, retransmission, dissemination or other use of, or taking 
of any action in reliance upon this information by persons or entities other 
than the intended recipient is prohibited. If you received this in error, 
please contact the sender and delete the material from all computers. 163

Re: OMB: IPv6 by June 2008

[David Conrad]

Alexei,

On Jul 7, 2005, at 9:58 AM, Alexei Roudnev wrote:
What's the problem with independent address space for every entity  
(company,

family, enterprise) which wants it?


It doesn't scale.  Regardless of Moore's law, there are some  
fundamental physical limits that constrain technology.



How many entities do we have on earth?


Well, there are 6 billion people on the planet.  Don't know how many  
companies or families.  Don't know how many autonomous devices there  
will be (e.g., cars, planes, boats, ships, satellites, light bulbs,  
gastro-intestinal probes, etc. etc.).



It was a problem, but it IS NOT ANYMORE.


You're not thinking big enough.

IPSec - see all ISAKMP schema and IPSEC security associations, and  
see IPSec

incompatibilities.


Any new protocol has initial interoperability problems when it is  
being developed by different people/teams.



Compare with SSL (works out-of-the-box in 99.999% cases,
and allows both, full and hard security with root certificates etc, or
simple security based on _ok, I trust you first time, then we can  
work_.


a) I suspect most SSL implementations derive out of the same code base.
b) SSL has been around longer.
c) SSLeay had lots of interoperability issues when it first came out.


Why MS uses PPTP? Because it is much more practuical vs IPSec.


MS uses PPTP because it meets their business requirements.  The fact  
that it is more practical is a second order effect.


Rgds,
-drc

RE: OMB: IPv6 by June 2008

[Kuhtz, Christian]

> > Compare with SSL (works out-of-the-box in 99.999% cases,
> > and allows both, full and hard security with root certificates etc,
or
> > simple security based on _ok, I trust you first time, then we can
> > work_.
> 
> If I'm on the same shared medium as you I can kill your SSL session
> with one packet.

Only if shared medium = vanilla CSMA/CD Ethernet or the like.

Just because 'transport' is shared, doesn't mean you as the consumer of
information carried by the network have visibility.


*
"The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential, proprietary, and/or privileged 
material.  Any review, retransmission, dissemination or other use of, or taking 
of any action in reliance upon, this information by persons or entities other 
than the intended recipient is prohibited.  If you received this in error, 
please contact the sender and delete the material from all computers."  118

RE: mh (RE: OMB: IPv6 by June 2008)

[Kuhtz, Christian]

> I've been poking around with end-host / end-network multihoming at the
> transport and application layers.  See, e.g., MONET, a multi-homed Web
> proxy designed to achieve high availability:
> 
>http://nms.lcs.mit.edu/ron/ronweb/
> 
> In general, this kind of end-host informed multihoming has a lot of
> potential for improving availability and performance (because the
> end-points actually see what they're getting), but at the cost of some
> extra implementation complexity.  The shim6 mechanism (in the general
> sense, not speaking to the specifics of shim6 negotiation, etc.), when
> augmented with some end-host smarts, could be a nice way to do
end-host
> based multihoming in the ipv6 context.

But, isn't that just a host based approach in the end and not a solution
for entire networks?  And if it isn't for entire networks, why do I need
any to any connectivity anyway?  I know, there's nothing that prevents
it (or any schema like it, including shim6) from being network to
network, but, good grief, what a huge amount of overhead to design
around a requirements flaw.  This sort of Moebius strip logic that's
used to explain/solve the problem which has been created is fun to
watch, but really just sucks in the end.

One could argue, however, that we don't need multihoming, we all need to
pour money into CDNs for things we really care about and lets somebody
else do the worrying.  .  And it all seems like such a hack. Hurray,
network based services are back.  The PSTN is dead, long live the PSTN.
Argh.  

Thanks,
Christian


The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential, proprietary, and/or privileged 
material. Any review, retransmission, dissemination or other use of, or taking 
of any action in reliance upon this information by persons or entities other 
than the intended recipient is prohibited. If you received this in error, 
please contact the sender and delete the material from all computers. 163

Re: OMB: IPv6 by June 2008

[Joe Abley]

On 2005-07-07, at 12:53, Alexei Roudnev wrote:

We have relatively PI address space in IPv4, which works fine, even  
with
current routers. No any problem to hold the whole world-wide  
routing with a
future ones. Is it a pproblem keeping 500,000 routess in core  
routers? Of
course, it is not (it was in 1996, but it is not in 2005 and it  
will not be
in 2008 - even if you will have 1,000,000 routes). IPv6 schema was  
build to
resolve problem which do not exists anymore (with fast CPU and  
cheap memory

and ASIC's).


Whether or not you see DFZ state growth as a serious enough issue to  
architect around depends on how much additional routing complexity  
you see in the network's future. Maybe there's the potential for  
50,000,000 routes in the DFZ if everybody who really wants to multi- 
home is able to do so; maybe it's higher. Regardless, there's still a  
point where the demand for routing slots will outstrip availability.


However, DFZ state bloat is not the only potential benefit to keeping  
multi-homing state at the edge of the network.


Here's an example, based in a future in which shim6 is successfully  
deployed in sufficient numbers of IP stacks that it can be considered  
commonplace, and consumer IPv6 internet access is easy to come by.  
This is a thought experiment; bear with me. I promise to shut up  
about shim6 after this message.


I have some devices in my home which require Internet connectivity --  
a handful of wireless base stations, some MP3 players, a couple of  
TiVO-style-things, an xbox in the basement, a few VoIP phones, a few  
laptops, etc. Maybe I even have the mythical Internet fridge, without  
which no forward-looking IPv6 thought experiment would be complete.


Since I can get both DSL and cable modem service for not much money  
(about $20/month each) and since I get grumpy when my Internet access  
goes away, I decide to buy both DSL and cable modem service. The more  
Internet-dependent devices I have in my house, the more attractive  
this option is.


Both Internet access services are delivered to my house in the form  
of small routers, which answer router solicitation messages each with  
EUI-64 addresses out of different PA /64s (one per provider).


My various networked devices each get two addresses in this way. When  
they talk to some remote device that has a shim6 element in its  
protocol stack, I get all the benefits that I would expect to achieve  
by multi-homing: if one provider goes down, I use the other one  
without having to debug anything, or yank any cables, or answer any  
difficult pop-up questions. Sessions that are established before one  
provider dies continue to work afterwards. New sessions start up just  
fine. When the provider comes back on-line, everything continues to  
work. I probably don't even notice that the provider had a problem.


My providers don't have to care that I am multi-homing. They deploy  
precisely the same infrastructure regardless of whether I am multi- 
homed or not. They don't have to talk BGP to me. They don't need a  
"multi-homing" product. I'm just a regular customer.


As a consumer, I don't even have to know what "multi-homing" is; I  
just need to order two (or more) completely independent Internet  
access services and have the installer plug them into the switch in  
my basement that connects everything else together.


This picture seems like it could scale to many millions of multi- 
homed end sites. It seems like it is eminently supportable. It seems  
like the kind of thing people would like to buy, if they knew they  
could.


If you compare this shim6/IPv6 picture to one in which every single  
multi-homed end site needs PI addresses and to announce a unique  
prefix into the DFZ in order to multi-home, then you either have a  
system which doesn't scale or you don't have much multi-homing going on.


If you compare this shim6/IPv6 picture to one in which the locator  
selection is done in NAT boxes instead of in the host protocol stack,  
then you have the additional complexity of NAT boxes communicating  
with each other to determine path reachability through their  
respective uplinks; you have coordination issues between multiple NAT  
boxes on an inside address ranges to us; you maybe even need some  
ability in hosts to switch their default routes between NAT boxes  
when paths through one stop working. And at the end of the day you  
still have NAT, with the attendant protocol kludges built into every  
P2P and telephony app to allow them squeeze around the middlebox  
minefield.



Joe

RE: OMB: IPv6 by June 2008

[Kuhtz, Christian]

> we're off on the usual strange tangents.  next will be whether
> it is ethical to walk in your neighbor's open house if they're
> running ipv6:-).

Why of course it is.  Afterall, anyone should be able to engage in any
(group hug|rape) at any time of their chosing with anyone else.  And if
you don't lock your door, barricade it, build a moat, with automatic
machine gun fire etc, well, then it's your fault that it happened to
you.. isn't it.  Afterall, you dressed for the part by showing up with
your own 128-bit ball and chain.  Except for the odd case where hugs are
actually being passed out.

Oh, sorry, was that too cynical?

> ipv4 has some problems.  the world has hacked around the major
> ones with things such as [holding nose] nat.  the ivtf came up
> with a technically weak second system syndrome patch which has
> yet to show enough sizzle to sell against the hacks to ipv4.
> so the ivtf, a decade out, is trying to hack to make it work.
> a shim on top of second system syndrome.  i am not holding my
> my breath.

Ditto.

> market physics will say whether scaling issues with nat et al.
> are sufficiently obnoxious to cause ipv6 to become sufficiently
> attractive; no amount of conjecturbation  here will change
> that.  if it becomes enabling and profitable, then folk will
> deploy and move.  if not, they won't.  life is simple.

It is possible that outside NA deployment volume may change NA
deployment habits.  We're already not in the driver seat with several
networking technologies as we previously were.  Plain old economics.  A
'maybe'.

The real question is if and how operators should prepare for their
deployments.  Some of us run a bit more than a mom and pop shop and when
massive infrastructures are being revamp where it would be nice if there
was a clear direction where to place bets.  Short of saying "hey, it's
all layer 2, why do I care."   

I guess I could always go pay a consultant for a "non answer". ;-)

Thanks,
Christian


The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential, proprietary, and/or privileged 
material. Any review, retransmission, dissemination or other use of, or taking 
of any action in reliance upon this information by persons or entities other 
than the intended recipient is prohibited. If you received this in error, 
please contact the sender and delete the material from all computers. 163

Re: OMB: IPv6 by June 2008

[David Meyer]

On Thu, Jul 07, 2005 at 09:58:56AM -0700, Alexei Roudnev wrote:
> 
> What's the problem with independent address space for every entity (company,
> family, enterprise) which wants it? Big routing tables? Is RT of 1,000,000
> routes BIG? I do not think so. Memory is cheap, modern routing schemas like
> CEF are effective. How many entities do we have on earth? It was a problem,
> but it IS NOT ANYMORE.

One of the problems that is frequently overlooked here is
that while the size of the DFZ is more or less bounded
(although not as meaningfully so for IPv6 as it is for
IPv4), the dynamic nature of the routing table is not
bounded. Add to this that the less aggregation you have,
the more the DFZ is exposed to those dynamics. The point
here being that the memory requirements of the DFZ table
is just one of the dimensions that must be considered if
we intend the network to scale. 

Dave





pgpqDJUAJZDNI.pgp
Description: PGP signature

Re: mh (RE: OMB: IPv6 by June 2008)

[David Andersen]

On Jul 7, 2005, at 1:09 PM, Kuhtz, Christian wrote:

As an easy-to-read overview of the shim6 approach, the following
rough draft may be useful:

   http://www.ietf.org/internet-drafts/draft-ietf-shim6-arch-00.txt



Thanks, I'm fully aware of where shim6 is right now.   I'm asking if
anyone feels this is headed anywhere useful or if we got anything else
we can use to facilitate mh.

To me, this is still a glaring hole as it has been for years now and
nobody seems to be making any fundamental progress here.  Partially
probably because the deck seems to be fundamentally stacked against mh,
which doesn't appear to have been a design criteria in the first place.


I've been poking around with end-host / end-network multihoming at the 
transport and application layers.  See, e.g., MONET, a multi-homed Web 
proxy designed to achieve high availability:


  http://nms.lcs.mit.edu/ron/ronweb/

In general, this kind of end-host informed multihoming has a lot of 
potential for improving availability and performance (because the 
end-points actually see what they're getting), but at the cost of some 
extra implementation complexity.  The shim6 mechanism (in the general 
sense, not speaking to the specifics of shim6 negotiation, etc.), when 
augmented with some end-host smarts, could be a nice way to do end-host 
based multihoming in the ipv6 context.


  -Dave

Re: OMB: IPv6 by June 2008

[Iljitsch van Beijnum]

On 7-jul-2005, at 18:58, Alexei Roudnev wrote:


Is RT of 1,000,000 routes BIG?


We've had this discussion very many times. Both the maximum number of  
routes routers can hold at any time in the future and the number of  
prefixes people are going to inject at that time are unknown. This  
makes it impossible to guarantee that the former is higher than the  
latter.



Compare with SSL (works out-of-the-box in 99.999% cases,
and allows both, full and hard security with root certificates etc, or
simple security based on _ok, I trust you first time, then we can  
work_.


If I'm on the same shared medium as you I can kill your SSL session  
with one packet.


IPv4 was strong because it was designed by practical people and not  
so much
by commiteets., IPv6 was designed by commiteets mainly. Do you  
know, that

'camel is horse designed by commiteet'?


So when is the last time you sent an ICMP source quench? Or set any  
of the low delay / high reliability / high throughput bits in the IP  
header?



- Original Message -


What am I, your janitor? Can't you throw your garbage in the trashcan?

RE: mh (RE: OMB: IPv6 by June 2008)

[Kuhtz, Christian]

> From: Joe Abley [mailto:[EMAIL PROTECTED]
> On 2005-07-07, at 10:10, Kuhtz, Christian wrote:
> 
> > Anyone here care to share operator perspectives shim6 and the
> > like?  Do
> > we actually have anything that anyone considers workable (not
whether
> > somebody can make it happen, but viable in a commercial
> > environment) for
> > mh?
> 
> There is no operational or implementation experience with shim6 at
> this time, that I know of (the technical specifications for shim6 are
> currently incomplete). The shim6 working group has its first meeting
> in August in Paris, after which the goal is to progress quickly to a
> set of specifications which can be implemented.
> 
> As an easy-to-read overview of the shim6 approach, the following
> rough draft may be useful:
> 
>http://www.ietf.org/internet-drafts/draft-ietf-shim6-arch-00.txt
>

Thanks, I'm fully aware of where shim6 is right now.   I'm asking if
anyone feels this is headed anywhere useful or if we got anything else
we can use to facilitate mh.  

To me, this is still a glaring hole as it has been for years now and
nobody seems to be making any fundamental progress here.  Partially
probably because the deck seems to be fundamentally stacked against mh,
which doesn't appear to have been a design criteria in the first place.

Thanks,
Christian


The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential, proprietary, and/or privileged 
material. Any review, retransmission, dissemination or other use of, or taking 
of any action in reliance upon this information by persons or entities other 
than the intended recipient is prohibited. If you received this in error, 
please contact the sender and delete the material from all computers. 163