Re: Waste will kill ipv6 too

[Owen DeLong]

Giving each nanobot a pair of /64s would be absurd. Maybe they aren’t all on 
the same link (there are no broadcast domains in IPv6), but likely a few /64s 
would cover each person. 

Owen


> On Dec 29, 2017, at 18:31, Michael Crapse  wrote:
> 
> And if a medical breakthrough happens within the next 30 years? Nanobots
> that process insulin for the diabetic, or take care of cancer, or repair
> your cells so you don't age, or whatever, perhaps the inventor things ipv6
> is a good idea for such an endeavour. a nanobot is microns wide, and there
> will be billions per person, hopefully not all on the same broadcast
> domain.In fact, as you saay, we should treat /64s as a /32 and a /64 for
> ptp. So each nanobot gets a /64. 10B nanobots per person times 20B people =
> oh, crap, we've exhausted the entirety of ipv6 an order of magnitude ago.
> Let alone the fact that actual usable ipv6 /64s is 2 orders of magnitude
> below that.
> 
> On 29 December 2017 at 19:12, Baldur Norddahl 
> wrote:
> 
>> Nobody needs to worry. I promise to reserve the last /32 out of my /29
>> assignment. When the world has run out of addresses, I will start to sell
>> from my pool using the same allocation policy that was used for IPv4. I
>> would consider a /64 to be equal a /32 IPv4 address. This would make a /56
>> assignment equal to a /24 IPv4 minimum assignment.
>> 
>> Historically we spent about 3 decades before running out of IPv4 space. So
>> my scheme should be good enough for some additional decades of IPv6.
>> 
>> I just hope nobody else does the same. That would be bad for my business
>> case.
>> 
>> Regards
>> 
>> Baldur
>> 
>> 
>> Den 30. dec. 2017 02.11 skrev "Scott Weeks" :
>> 
>>> 
>>> --- jlightf...@gmail.com wrote:
>>> From: John Lightfoot 
>>> 
>>> Excuse the top post, but this seems to be an
>>> argument between people who understand big
>>> numbers and those who don't.
>>> 
>>> 
>>> No, not exactly.  It's also about those that
>>> think in current/past network terms and those
>>> who are saying we don't know what the future
>>> holds, so we should be careful.
>>> 
>>> 
>>> 
>>> -
>>> which means 79 octillion people...no one
>>> alive will be around
>>> -
>>> 
>>> Stop thinking in terms of people.  Think in
>>> terms of huge numbers of 'things' in the
>>> ocean, in the atmosphere, in space, zillions
>>> of 'things' on and around everyone's bodies
>>> and homes and myriad other 'things' we can't
>>> even imagine right now.
>>> 
>>> scott
>>> 
>> 

Re: Waste will kill ipv6 too

[Owen DeLong]

> On Dec 29, 2017, at 17:11, Scott Weeks  wrote:
> 
> 
> --- jlightf...@gmail.com wrote:
> From: John Lightfoot 
> 
> Excuse the top post, but this seems to be an 
> argument between people who understand big 
> numbers and those who don't.  
> 
> 
> No, not exactly.  It's also about those that 
> think in current/past network terms and those 
> who are saying we don't know what the future 
> holds, so we should be careful.
> 
> 
> 
> -
> which means 79 octillion people...no one 
> alive will be around
> -
> 
> Stop thinking in terms of people.  Think in 
> terms of huge numbers of 'things' in the 
> ocean, in the atmosphere, in space, zillions 
> of 'things' on and around everyone's bodies 
> and homes and myriad other 'things' we can't 
> even imagine right now.

Sure, but likely zillions of ocean sensors will share a few /64s rather than 
getting a /48 each. 

Do you really think each person needs more than a thousand or so subnets for 
their wearable sensors? If not, then 1 of the many /48s they can safely consume 
has them covered. 

Can I see a possible future in which homes actually need /48s? Sure. But we’ve 
got more than enough /48s to do that.

As I’ve said many times before, let’s see how it goes with the first /3 doing 
things as designed and intended. If it turns out to consume that 1/8th of the 
address space while I’m still alive, I’ll happily help build more restrictive 
allocation policies for the remaining virgin 5/8ths and the fractions of the 
1/4 of the address that have a very small number of special use carve-outs 
(0::/3 and e000::/3). 

Given that we still have more than 500 /12s free in the first /3 20 years into 
the process, I’m thinking we aren’t likely to have that issue. 

Owen

> 
> scott

Re: 48vDC Output UPS

[Bryan Holloway]

Eltek is worth a look. Really solid stuff. Used them for awhile now.

If you want battery back-up, it'll probably take more than 3 RU, though.


On 12/29/17 9:16 PM, Lewis,Mitchell T. wrote:

I should have been more specific(Quite obvious by the responses I have been 
getting). I am looking for a rack mount rectifier type device for a remote site(Not 
a Datacenter/Colo) which outputs 48vdc & has an 120vac input. I would like it 
to be remote monitor-able via snmp(battery charge, running on batteries etc). I am 
looking for a runtime of about an hour at about 500w load. A built in battery would 
be great but an external battery would work as well-I would like the whole setup to 
be no more than 3ru.

The purpose this device will serve to allow remote monitoring of power 
conditions(Advance Power Outage Notification, Power Glitches etc) as well as 
power the connected devices for a short while in the event of a power 
glitch(Brown-Out, Power outages up to 30-45 minutes etc).

I hope this help clarify.


Thanks & Regards,

Mitchell T. Lewis

[ mailto:mle...@techcompute.net | mle...@techcompute.net ]


[ http://linkedin.com/in/mlewiscc ] |203-816-0371

PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ 
https://pgp.mit.edu/pks/lookup?op=get=0x2AFA805732A1394E | Public PGP 
Key ]



From: "William Herrin" 
To: "Lewis,Mitchell T." 
Cc: "NANOG" 
Sent: Friday, December 29, 2017 10:05:15 PM
Subject: Re: 48vDC Output UPS

On Fri, Dec 29, 2017 at 7:58 PM, Lewis,Mitchell T. < [ 
mailto:ml-na...@techcompute.net | ml-na...@techcompute.net ] > wrote:


I have been looking for a Rack Mount UPS that accepts AC power input but has 
48vdc output(telco voltage). Anyone have any recommendations?



Hi Mitchell,

That's not usually called an UPS. What you need is a Rectifier that feeds a -48 
battery system. You connect your equipment the battery and make sure the 
rectifier system puts out enough wattage to both power the equipment and keep 
the battery topped off.

Try searching ebay for "rack rectifier"

Regards,
Bill Herrin

Re: Waste will kill ipv6 too

[Randy Bush]

the good thing about these long threads, which have ZERO new
information, is having a KillThread command in one's mail user agent.
get a life!

Re: Waste will kill ipv6 too

[Scott Weeks]

--- br...@ampr.org wrote:
From: Brian Kantor 

Just how many nanobots can dance on the head of a pin?
---


2^128?  Just guessing.  >;-)

scott

Re: 48vDC Output UPS

[Lewis,Mitchell T.]

I should have been more specific(Quite obvious by the responses I have been 
getting). I am looking for a rack mount rectifier type device for a remote 
site(Not a Datacenter/Colo) which outputs 48vdc & has an 120vac input. I would 
like it to be remote monitor-able via snmp(battery charge, running on batteries 
etc). I am looking for a runtime of about an hour at about 500w load. A built 
in battery would be great but an external battery would work as well-I would 
like the whole setup to be no more than 3ru. 

The purpose this device will serve to allow remote monitoring of power 
conditions(Advance Power Outage Notification, Power Glitches etc) as well as 
power the connected devices for a short while in the event of a power 
glitch(Brown-Out, Power outages up to 30-45 minutes etc). 

I hope this help clarify. 


Thanks & Regards, 

Mitchell T. Lewis 

[ mailto:mle...@techcompute.net | mle...@techcompute.net ] 


[ http://linkedin.com/in/mlewiscc ] |203-816-0371 

PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ 
https://pgp.mit.edu/pks/lookup?op=get=0x2AFA805732A1394E | Public PGP 
Key ] 



From: "William Herrin"  
To: "Lewis,Mitchell T."  
Cc: "NANOG"  
Sent: Friday, December 29, 2017 10:05:15 PM 
Subject: Re: 48vDC Output UPS 

On Fri, Dec 29, 2017 at 7:58 PM, Lewis,Mitchell T. < [ 
mailto:ml-na...@techcompute.net | ml-na...@techcompute.net ] > wrote: 


I have been looking for a Rack Mount UPS that accepts AC power input but has 
48vdc output(telco voltage). Anyone have any recommendations? 



Hi Mitchell, 

That's not usually called an UPS. What you need is a Rectifier that feeds a -48 
battery system. You connect your equipment the battery and make sure the 
rectifier system puts out enough wattage to both power the equipment and keep 
the battery topped off. 

Try searching ebay for "rack rectifier" 

Regards, 
Bill Herrin 


-- 
William Herrin  [ mailto:her...@dirtside.com | 
her...@dirtside.com ] [ mailto:b...@herrin.us | b...@herrin.us ] 
Dirtside Systems . Web: < [ http://www.dirtside.com/ | 
http://www.dirtside.com/ ] > 

Re: Waste will kill ipv6 too

[William Herrin]

On Fri, Dec 29, 2017 at 8:11 PM, Scott Weeks  wrote:

> Stop thinking in terms of people.  Think in
> terms of huge numbers of 'things' in the
> ocean, in the atmosphere, in space, zillions
> of 'things' on and around everyone's bodies
> and homes and myriad other 'things' we can't
> even imagine right now.
>

Think in terms of system architectures where the address space is fully
consumed when empty to more than 20 decimal places. Because we're idiots
and actually designed it that way.



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: 48vDC Output UPS

[William Herrin]

On Fri, Dec 29, 2017 at 7:58 PM, Lewis,Mitchell T.  wrote:

> I have been looking for a Rack Mount UPS that accepts AC power input but
> has 48vdc output(telco voltage). Anyone have any recommendations?
>

Hi Mitchell,

That's not usually called an UPS. What you need is a Rectifier that feeds a
-48 battery system. You connect your equipment the battery and make sure
the rectifier system puts out enough wattage to both power the equipment
and keep the battery topped off.

Try searching ebay for "rack rectifier"

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: 48vDC Output UPS

[Brock Tice]

On December 29, 2017 5:58:02 PM MST, "Lewis,Mitchell T." 
 wrote:
>Greetings again, 
>I have been looking for a Rack Mount UPS that accepts AC power input
>but has 48vdc output(telco voltage). Anyone have any recommendations? 
>
>
>
>Regards, 
>
>Mitchell T. Lewis 
>
>[ mailto:mle...@techcompute.net | mle...@techcompute.net ] 
>
>
>[ http://linkedin.com/in/mlewiscc ] |203-816-0371 
>
>PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [
>https://pgp.mit.edu/pks/lookup?op=get=0x2AFA805732A1394E |
>Public PGP Key ] 
>   

Samlex makes a nice one. 25A output.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Waste will kill ipv6 too

[Brian Kantor]

On Sat, Dec 30, 2017 at 02:46:49AM +, Gary Buhrmaster wrote:
> (the time has finally arrived)
> Obligatory xkcd ref:  https://xkcd.com/865/

Just how many nanobots can dance on the head of a pin?
- Brian

Re: Waste will kill ipv6 too

[Gary Buhrmaster]

On Sat, Dec 30, 2017 at 2:31 AM, Michael Crapse  wrote:
> And if a medical breakthrough happens within the next 30 years? Nanobots
> that process insulin for the diabetic, or take care of cancer, or repair
> your cells so you don't age, or whatever, perhaps the inventor things ipv6
> is a good idea for such an endeavour. a nanobot is microns wide, and there
> will be billions per person, hopefully not all on the same broadcast
> domain.In fact, as you saay, we should treat /64s as a /32 and a /64 for
> ptp. So each nanobot gets a /64. 10B nanobots per person times 20B people =
> oh, crap, we've exhausted the entirety of ipv6 an order of magnitude ago.
> Let alone the fact that actual usable ipv6 /64s is 2 orders of magnitude
> below that.

(the time has finally arrived)

Obligatory xkcd ref:  https://xkcd.com/865/

Re: Waste will kill ipv6 too

[Michael Crapse]

And if a medical breakthrough happens within the next 30 years? Nanobots
that process insulin for the diabetic, or take care of cancer, or repair
your cells so you don't age, or whatever, perhaps the inventor things ipv6
is a good idea for such an endeavour. a nanobot is microns wide, and there
will be billions per person, hopefully not all on the same broadcast
domain.In fact, as you saay, we should treat /64s as a /32 and a /64 for
ptp. So each nanobot gets a /64. 10B nanobots per person times 20B people =
oh, crap, we've exhausted the entirety of ipv6 an order of magnitude ago.
Let alone the fact that actual usable ipv6 /64s is 2 orders of magnitude
below that.

On 29 December 2017 at 19:12, Baldur Norddahl 
wrote:

> Nobody needs to worry. I promise to reserve the last /32 out of my /29
> assignment. When the world has run out of addresses, I will start to sell
> from my pool using the same allocation policy that was used for IPv4. I
> would consider a /64 to be equal a /32 IPv4 address. This would make a /56
> assignment equal to a /24 IPv4 minimum assignment.
>
> Historically we spent about 3 decades before running out of IPv4 space. So
> my scheme should be good enough for some additional decades of IPv6.
>
> I just hope nobody else does the same. That would be bad for my business
> case.
>
> Regards
>
> Baldur
>
>
> Den 30. dec. 2017 02.11 skrev "Scott Weeks" :
>
> >
> > --- jlightf...@gmail.com wrote:
> > From: John Lightfoot 
> >
> > Excuse the top post, but this seems to be an
> > argument between people who understand big
> > numbers and those who don't.
> > 
> >
> > No, not exactly.  It's also about those that
> > think in current/past network terms and those
> > who are saying we don't know what the future
> > holds, so we should be careful.
> >
> >
> >
> > -
> > which means 79 octillion people...no one
> > alive will be around
> > -
> >
> > Stop thinking in terms of people.  Think in
> > terms of huge numbers of 'things' in the
> > ocean, in the atmosphere, in space, zillions
> > of 'things' on and around everyone's bodies
> > and homes and myriad other 'things' we can't
> > even imagine right now.
> >
> > scott
> >
>

Re: Waste will kill ipv6 too

[Scott Weeks]

--- baldur.nordd...@gmail.com wrote:
From: Baldur Norddahl 

Nobody needs to worry...Historically we spent...
--


Out of context, but yeah that.

scott

Re: 48vDC Output UPS

[Brandon Martin]

On 12/29/2017 07:58 PM, Lewis,Mitchell T. wrote:

Greetings again,
I have been looking for a Rack Mount UPS that accepts AC power input but has 
48vdc output(telco voltage). Anyone have any recommendations?



Are you saying you want a 48V battery but AC in and AC to the devices 
being provided uninterruptible power, or do you want AC in and 48V DC 
out for both storage and devices being powered?


If the latter, any reason not to just run conventional telecom-style DC 
plant with a "rectifier", stack(s) of 48V worth of lead-acid batteries, 
and appropriate DC power distribution?


If the former, Tripp-Lite has several options that I like.  You can get 
an "inverter/charger" (which is basically a UPS sans batteries) or many 
products in their SmartOnline (SU...) series have 48V batteries which 
can be external and (warranty/support issues aside as well as possible 
regulatory hassles) don't really care how big the battery bank is.


--
Brandon Martin

Re: Waste will kill ipv6 too

[Baldur Norddahl]

Nobody needs to worry. I promise to reserve the last /32 out of my /29
assignment. When the world has run out of addresses, I will start to sell
from my pool using the same allocation policy that was used for IPv4. I
would consider a /64 to be equal a /32 IPv4 address. This would make a /56
assignment equal to a /24 IPv4 minimum assignment.

Historically we spent about 3 decades before running out of IPv4 space. So
my scheme should be good enough for some additional decades of IPv6.

I just hope nobody else does the same. That would be bad for my business
case.

Regards

Baldur


Den 30. dec. 2017 02.11 skrev "Scott Weeks" :

>
> --- jlightf...@gmail.com wrote:
> From: John Lightfoot 
>
> Excuse the top post, but this seems to be an
> argument between people who understand big
> numbers and those who don't.
> 
>
> No, not exactly.  It's also about those that
> think in current/past network terms and those
> who are saying we don't know what the future
> holds, so we should be careful.
>
>
>
> -
> which means 79 octillion people...no one
> alive will be around
> -
>
> Stop thinking in terms of people.  Think in
> terms of huge numbers of 'things' in the
> ocean, in the atmosphere, in space, zillions
> of 'things' on and around everyone's bodies
> and homes and myriad other 'things' we can't
> even imagine right now.
>
> scott
>

Re: 48vDC Output UPS

[Brian Kantor]

On Fri, Dec 29, 2017 at 04:58:02PM -0800, Lewis,Mitchell T. wrote:
> Greetings again, 
> I have been looking for a Rack Mount UPS that accepts AC power input but has 
> 48vdc output(telco voltage). Anyone have any recommendations? 
> Regards, 
> Mitchell T. Lewis 
> [ mailto:mle...@techcompute.net | mle...@techcompute.net ] 
> [ http://linkedin.com/in/mlewiscc ] |203-816-0371 
> PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ 
> https://pgp.mit.edu/pks/lookup?op=get=0x2AFA805732A1394E | Public PGP 
> Key ] 

A word of caution (I was bitten by this): in many data centers,
the USA National Electrical Code requires that UPS units be
connected to the Emergency Power Off system so that in case of
emergency the UPS will shut off too.  Many of the less expensive
UPS units do not have EPO shutdown capability, and it usually
takes an electrician to wire it up when they do.  

There are also NEC regulations regarding batteries.
- Brian

Re: Waste will kill ipv6 too

[Mel Beckman]

I'm saying I should be able to use whatever size LAN I want.

Go ahead. Just don't use anybody else's addresses to do it. :)

 -mel

On Dec 29, 2017, at 4:52 PM, John Lightfoot 
> wrote:

Excuse the top post, but this seems to be an argument between people who 
understand big numbers and those who don't.  IPv4 has 2^32 addresses, IPv6 has 
2^128, which means 79 octillion people can each have their own internet.  I 
think Owen is being modest when he says no one alive will be around for the 
exhaustion of IPv6, I think we're debating whether it will run out in a 
thousand years or a million.

On 12/29/17, 10:44 AM, "NANOG on behalf of Owen DeLong" 
 on behalf of 
o...@delong.com> wrote:



On Dec 28, 2017, at 18:54, Ricky Beam 
> wrote:

On Thu, 28 Dec 2017 21:05:33 -0500, Owen DeLong 
> wrote:
If you want to make that argument, that we shouldn’t have SLAAC and we should 
use /96 prefixes, that wouldn’t double the space, it would multiply it by 
roughly 4 billion.

I'm saying I should be able to use whatever size LAN I want.

   Sounds like you already are and nobody is telling you that you can’t. It’s a 
rather silly way to over-complicate your life, but if you want to be on the 
wrong side of a direcTV commercial, nobody’s trying to stop you.


The routing problem might be real if everyone goes to PI, but I think that’s an 
unlikely scenario.

Every scenario everyone has come up with is "unlikely". Home networks with 
multiple LANs??? Never going to happen; people don't know how to set them up, 
and there's little technical need for it.

   Lots of home networks have multiple LANs today, so you’re patently wrong 
there already.


Your definition of “amazingly fast is pretty odd... we’ve allocated tiny 
fractions of 2 /3 prefixes to special uses (multicast, ULA, loopback, unknown, 
etc.). Beyond that, there’s a /3 delegated to IANA as unicast space for 
distribution to the RIRs. Of that /3, IANA has delegated a little more than 5 
/12s to RIRs. That’s the total of 20 years worth of turkey carving and 
constitutes well under 1/8th of the address space. Issued. By that measure, 
we’ve got well over 160 years to worry about runout.

After 20 years of not using IPv6, that's actually A LOT of carving. And if you 
look at what's been assigned vs. what's being announced vs. what's actually 
being used, there's a fantastic amount of waste. But nobody cares because 
there's plenty of space, and "we'll never use it all." (history says otherwise.)

   Given that more than 50% of US mobile traffic is now IPv6, I find it hard to 
give credence to a claim of “not using”. It’s also north of 40% for US fixed 
wire line traffic.

   As I said, I don’t doubt that we may eventually run out. However, I doubt 
anyone alive today will still be alive when we do.

   Owen

Re: 48vDC Output UPS

[João Butzke]

Mitchell,

You can use Emerson Netsure 
(https://www.vertivco.com/en-us/products/brands/netsure/)


You need to set next to the rack a battery bank ( 4x12v = 48v batteries 
in series )


Best Regards,
João Butzke.

Em 29/12/2017 22:58, Lewis,Mitchell T. escreveu:

Greetings again,
I have been looking for a Rack Mount UPS that accepts AC power input but has 
48vdc output(telco voltage). Anyone have any recommendations?



Regards,

Mitchell T. Lewis

[ mailto:mle...@techcompute.net | mle...@techcompute.net ]


[ http://linkedin.com/in/mlewiscc ] |203-816-0371

PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ 
https://pgp.mit.edu/pks/lookup?op=get=0x2AFA805732A1394E | Public PGP 
Key ]

Re: Waste will kill ipv6 too

[Scott Weeks]

--- jlightf...@gmail.com wrote:
From: John Lightfoot 

Excuse the top post, but this seems to be an 
argument between people who understand big 
numbers and those who don't.  


No, not exactly.  It's also about those that 
think in current/past network terms and those 
who are saying we don't know what the future 
holds, so we should be careful.



-
which means 79 octillion people...no one 
alive will be around
-

Stop thinking in terms of people.  Think in 
terms of huge numbers of 'things' in the 
ocean, in the atmosphere, in space, zillions 
of 'things' on and around everyone's bodies 
and homes and myriad other 'things' we can't 
even imagine right now.

scott

48vDC Output UPS

[Lewis,Mitchell T.]

Greetings again, 
I have been looking for a Rack Mount UPS that accepts AC power input but has 
48vdc output(telco voltage). Anyone have any recommendations? 



Regards, 

Mitchell T. Lewis 

[ mailto:mle...@techcompute.net | mle...@techcompute.net ] 


[ http://linkedin.com/in/mlewiscc ] |203-816-0371 

PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ 
https://pgp.mit.edu/pks/lookup?op=get=0x2AFA805732A1394E | Public PGP 
Key ] 

Re: Waste will kill ipv6 too

[John Lightfoot]

Excuse the top post, but this seems to be an argument between people who 
understand big numbers and those who don't.  IPv4 has 2^32 addresses, IPv6 has 
2^128, which means 79 octillion people can each have their own internet.  I 
think Owen is being modest when he says no one alive will be around for the 
exhaustion of IPv6, I think we're debating whether it will run out in a 
thousand years or a million. 

On 12/29/17, 10:44 AM, "NANOG on behalf of Owen DeLong" 
 wrote:



> On Dec 28, 2017, at 18:54, Ricky Beam  wrote:
> 
>> On Thu, 28 Dec 2017 21:05:33 -0500, Owen DeLong  wrote:
>> If you want to make that argument, that we shouldn’t have SLAAC and we 
should use /96 prefixes, that wouldn’t double the space, it would multiply it 
by roughly 4 billion.
> 
> I'm saying I should be able to use whatever size LAN I want.

Sounds like you already are and nobody is telling you that you can’t. It’s 
a rather silly way to over-complicate your life, but if you want to be on the 
wrong side of a direcTV commercial, nobody’s trying to stop you. 

> 
>> The routing problem might be real if everyone goes to PI, but I think 
that’s an unlikely scenario.
> 
> Every scenario everyone has come up with is "unlikely". Home networks 
with multiple LANs??? Never going to happen; people don't know how to set them 
up, and there's little technical need for it.

Lots of home networks have multiple LANs today, so you’re patently wrong 
there already. 

> 
>> Your definition of “amazingly fast is pretty odd... we’ve allocated tiny 
fractions of 2 /3 prefixes to special uses (multicast, ULA, loopback, unknown, 
etc.). Beyond that, there’s a /3 delegated to IANA as unicast space for 
distribution to the RIRs. Of that /3, IANA has delegated a little more than 5 
/12s to RIRs. That’s the total of 20 years worth of turkey carving and 
constitutes well under 1/8th of the address space. Issued. By that measure, 
we’ve got well over 160 years to worry about runout.
> 
> After 20 years of not using IPv6, that's actually A LOT of carving. And 
if you look at what's been assigned vs. what's being announced vs. what's 
actually being used, there's a fantastic amount of waste. But nobody cares 
because there's plenty of space, and "we'll never use it all." (history says 
otherwise.)

Given that more than 50% of US mobile traffic is now IPv6, I find it hard 
to give credence to a claim of “not using”. It’s also north of 40% for US fixed 
wire line traffic. 

As I said, I don’t doubt that we may eventually run out. However, I doubt 
anyone alive today will still be alive when we do. 

Owen

Re: Wi-Fi Analyzer

[Eric Kuhnke]

In addition to the other tools already recommended by previous posters, I
recommend buying one of these:

https://www.ubnt.com/airmax/nanobeam-ac-gen2/

It's a directional antenna/radio integrated unit and is intended as a point
to point or point-to-multipoint WISP client radio. The one feature you can
get from it very cheaply is a directional, 2x2 MIMO 5.x GHz band spectrum
analyzer that sees things *which are not 802.11 or wifi based.*

The airview spectrum analyzer tool built into it looks like this:
https://www.google.com/search?q=ubiquiti+airview=100=lnms=isch=X=0ahUKEwj0gtLI9q_YAhUC62MKHbZoAogQ_AUICygC=1744=994=1.1

Highly useful for tracking down a specific source of non-wifi 5 GHz band
interference. There's all sorts of random consumer grade things people can
buy and introduce into an environment which do not broadcast MAC addresses
or SSIDs, and do not show up on purely 802.11(abgn/ac) based tools.

It will of course also see hidden SSIDs and standard+non-standard
802.11abgn(ac) emitters.

There are also 2.4 GHz versions of similar products which will let you find
non-802.11 emitters in the 2300 to 2500 MHz band. At $79 a lot less
expensive than a "real" spectrum analyzer.

You can get DC PoE injectors for them which will connect to a Makita drill
battery if you want to make it portable and wander around with a laptop.


On Fri, Dec 29, 2017 at 7:17 AM, Bryan Holloway  wrote:

> Curious if the community has any recommendations and/or positive
> experiences to share for a handheld Wi-Fi (802.11a/b/g/n/ac) analyzer.
>
> Software/laptop-based solutions can be unwieldy in certain environments.
> However, given rave reviews, I'm open to the idea as long as it's
> Mac-compatible.
>
> Should be able to show detailed spectra, help locate sources of
> interference, have mapping capabilities, etc.
>
> Thanks!
>

Re: Wi-Fi Analyzer

[Sean Heskett]

iStumbler on the Mac

-Sean



On Fri, Dec 29, 2017 at 8:17 AM Bryan Holloway  wrote:

> Curious if the community has any recommendations and/or positive
> experiences to share for a handheld Wi-Fi (802.11a/b/g/n/ac) analyzer.
>
> Software/laptop-based solutions can be unwieldy in certain environments.
> However, given rave reviews, I'm open to the idea as long as it's
> Mac-compatible.
>
> Should be able to show detailed spectra, help locate sources of
> interference, have mapping capabilities, etc.
>
> Thanks!
>

Re: Wi-Fi Analyzer

[Richard]

Sorry for the top post, but I too end up going back to Wi Fi analyzer on 
my Android. I have found it covers all the basics which i need and am 
able to locate any difficulty I may be having. It works and you can 
carry it in your pocket instead of dragging a laptop around.


Richard


On 12/29/2017 09:17 AM, Bryan Holloway wrote:
Curious if the community has any recommendations and/or positive 
experiences to share for a handheld Wi-Fi (802.11a/b/g/n/ac) analyzer.


Software/laptop-based solutions can be unwieldy in certain 
environments. However, given rave reviews, I'm open to the idea as 
long as it's Mac-compatible.


Should be able to show detailed spectra, help locate sources of 
interference, have mapping capabilities, etc.


Thanks!

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG, CaribNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 30 Dec, 2017

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  677557
Prefixes after maximum aggregation (per Origin AS):  263618
Deaggregation factor:  2.57
Unique aggregates announced (without unneeded subnets):  328121
Total ASes present in the Internet Routing Table: 59472
Prefixes per ASN: 11.39
Origin-only ASes present in the Internet Routing Table:   51332
Origin ASes announcing only one prefix:   22605
Transit ASes present in the Internet Routing Table:8140
Transit-only ASes present in the Internet Routing Table:256
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  30
Max AS path prepend of ASN ( 29046)  25
Prefixes from unregistered ASNs in the Routing Table:88
Number of instances of unregistered ASNs:89
Number of 32-bit ASNs allocated by the RIRs:  21049
Number of 32-bit ASNs visible in the Routing Table:   16874
Prefixes from 32-bit ASNs in the Routing Table:   69320
Number of bogon 32-bit ASNs visible in the Routing Table:11
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:325
Number of addresses announced to Internet:   2859634018
Equivalent to 170 /8s, 114 /16s and 141 /24s
Percentage of available address space announced:   77.2
Percentage of allocated address space announced:   77.2
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.8
Total number of prefixes smaller than registry allocations:  224347

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   186321
Total APNIC prefixes after maximum aggregation:   53408
APNIC Deaggregation factor:3.49
Prefixes being announced from the APNIC address blocks:  185448
Unique aggregates announced from the APNIC address blocks:77495
APNIC Region origin ASes present in the Internet Routing Table:8557
APNIC Prefixes per ASN:   21.67
APNIC Region origin ASes announcing only one prefix:   2420
APNIC Region transit ASes present in the Internet Routing Table:   1250
Average APNIC Region AS path length visible:4.3
Max APNIC Region AS path length visible: 29
Number of APNIC region 32-bit ASNs visible in the Routing Table:   3442
Number of APNIC addresses announced to Internet:  770161954
Equivalent to 45 /8s, 231 /16s and 189 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-137529
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:202626
Total ARIN prefixes after maximum aggregation:97583
ARIN Deaggregation factor: 2.08
Prefixes being announced from the ARIN address blocks:   203867
Unique aggregates announced from the ARIN address blocks: 95602
ARIN Region origin ASes present in the Internet Routing Table:18039
ARIN Prefixes per ASN:  

Re: Waste will kill ipv6 too

[William Herrin]

On Fri, Dec 29, 2017 at 5:27 AM,  wrote:

> It's rather interesting how parsing of variable length addresses was
> thought to be way too complicated - while parsing of IPv6 extension
> header chains of unknown length was okay.
>

IIRC, IPv6 extension headers are optional. The router does have to check if
there are any hop-by-hop options but it doesn't need to examine more than
the first extension header (and always the same byte offset) to determine
if it has to look. More, it's allowed to reject the packet with a parameter
problem rather than process the header.

The originating and destination nodes have to pay attention to all
extension headers, but then they always did have to process packets with
information of variable lengths.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: Wi-Fi Analyzer

[Troy Martin]

For OSX specific requirement, I suggest looking at “Wi-Fi Explorer Pro”.  It 
scans for SSIDs, integrates with Metageek Wi-Spy for SpecA, connects to remote 
sensors.  Eval for 10 days before needing pay.

The developer (Adrian Granados) also makes a tool called “Wi-Fi signal” (menu 
bar display/status).

There is another tool as well “Airtool” which makes packet captures 
ridiculously easy on OSX.

For mapping Ekahau or Netapot which are OSX based.  Alternatively - iBwave, 
Ekahau, Airmagnet and Tamosoft on windows.

Kindest regards,

--
Troy Martin



> On Dec 29, 2017, at 8:45 AM, Alan Buxey  wrote:
> 
> Scout Aircheck G2 is quite nifty - but a lot of tools out there are
> only just a little bit above what you can do with a decent Android
> phone (one with 802.11a/b/g/n/ac chipset) and
> WiFiAnalyzer !  :)
> 
> alan

Re: Waste will kill ipv6 too

[Nick Hilliard]

Owen DeLong wrote:
> fast routers mostly don’t parse those chains.

...unless they need to access the L4 header information in order to
create useful hashes to load balance over LAG or ECMP bundles, or
implement any sort of filtering, or RE / control plane policing.

But outside these corner cases, definitely a minority requirement :-)

Nick

Re: Waste will kill ipv6 too

[Owen DeLong]

On Dec 29, 2017, at 02:27, sth...@nethelp.no wrote:

>>> My wild guess is if we'd just waited a little bit longer to formalize
>>> IPng we'd've more seriously considered variable length addressing with
>>> a byte indicating how many octets in the address even if only 2
>>> lengths were immediately implemented (4 and 16.)
>> 
>> Actually, that got heaved over the side fairly early in the IPng discussion,
>> because nobody  who was building silicon last century wanted to
>> deal with arbitrary-length addresses.  The IPv4 header had source and
>> destination addresses on 4-byte boundaries for good reasons which
>> still held true when we did the IPv6 headers.
> 
> It's rather interesting how parsing of variable length addresses was
> thought to be way too complicated - while parsing of IPv6 extension
> header chains of unknown length was okay.

Well... first, fast routers mostly don’t parse those chains. Second, to the 
extent they do, it’s the biggest legitimate complaint I’ve seen with the design 
of IPv6. 

Owen

> 
> Steinar Haug, Nethelp consulting, sth...@nethelp.no

Re: Wi-Fi Analyzer

[Alan Buxey]

Scout Aircheck G2 is quite nifty - but a lot of tools out there are
only just a little bit above what you can do with a decent Android
phone (one with 802.11a/b/g/n/ac chipset) and
WiFiAnalyzer !  :)

alan

Re: Waste will kill ipv6 too

[Owen DeLong]

> On Dec 28, 2017, at 18:54, Ricky Beam  wrote:
> 
>> On Thu, 28 Dec 2017 21:05:33 -0500, Owen DeLong  wrote:
>> If you want to make that argument, that we shouldn’t have SLAAC and we 
>> should use /96 prefixes, that wouldn’t double the space, it would multiply 
>> it by roughly 4 billion.
> 
> I'm saying I should be able to use whatever size LAN I want.

Sounds like you already are and nobody is telling you that you can’t. It’s a 
rather silly way to over-complicate your life, but if you want to be on the 
wrong side of a direcTV commercial, nobody’s trying to stop you. 

> 
>> The routing problem might be real if everyone goes to PI, but I think that’s 
>> an unlikely scenario.
> 
> Every scenario everyone has come up with is "unlikely". Home networks with 
> multiple LANs??? Never going to happen; people don't know how to set them up, 
> and there's little technical need for it.

Lots of home networks have multiple LANs today, so you’re patently wrong there 
already. 

> 
>> Your definition of “amazingly fast is pretty odd... we’ve allocated tiny 
>> fractions of 2 /3 prefixes to special uses (multicast, ULA, loopback, 
>> unknown, etc.). Beyond that, there’s a /3 delegated to IANA as unicast space 
>> for distribution to the RIRs. Of that /3, IANA has delegated a little more 
>> than 5 /12s to RIRs. That’s the total of 20 years worth of turkey carving 
>> and constitutes well under 1/8th of the address space. Issued. By that 
>> measure, we’ve got well over 160 years to worry about runout.
> 
> After 20 years of not using IPv6, that's actually A LOT of carving. And if 
> you look at what's been assigned vs. what's being announced vs. what's 
> actually being used, there's a fantastic amount of waste. But nobody cares 
> because there's plenty of space, and "we'll never use it all." (history says 
> otherwise.)

Given that more than 50% of US mobile traffic is now IPv6, I find it hard to 
give credence to a claim of “not using”. It’s also north of 40% for US fixed 
wire line traffic. 

As I said, I don’t doubt that we may eventually run out. However, I doubt 
anyone alive today will still be alive when we do. 

Owen

Re: Wi-Fi Analyzer

[Brian Reichert]

On Fri, Dec 29, 2017 at 09:17:26AM -0600, Bryan Holloway wrote:
> Curious if the community has any recommendations and/or positive 
> experiences to share for a handheld Wi-Fi (802.11a/b/g/n/ac) analyzer.
> 
> Software/laptop-based solutions can be unwieldy in certain environments. 
> However, given rave reviews, I'm open to the idea as long as it's 
> Mac-compatible.
> 
> Should be able to show detailed spectra, help locate sources of 
> interference, have mapping capabilities, etc.

Depending on what problem you're trying to solve, on my Android
phone I use a free app called 'Wifi Analyzer':

  http://wifianalyzer.mobi

Shows me what station IDs are on what channels, handles 2.4g and 5G
connections, etc.

Doesn't provide mapping, just shows "from where I am right know, what
channels have which stations as what strengths?"

For a house, it's easy to walk around, to passively get a feel for Wifi
placement/config.


> Thanks!

-- 
Brian Reichert  
BSD admin/developer at large

Re: Waste will kill ipv6 too

[Nick Hilliard]

>>> My wild guess is if we'd just waited a little bit longer to formalize
>>> IPng we'd've more seriously considered variable length addressing with
>>> a byte indicating how many octets in the address even if only 2
>>> lengths were immediately implemented (4 and 16.)
>> Actually, that got heaved over the side fairly early in the IPng discussion,
>> because nobody  who was building silicon last century wanted to
>> deal with arbitrary-length addresses.  The IPv4 header had source and
>> destination addresses on 4-byte boundaries for good reasons which
>> still held true when we did the IPv6 headers.
> 
> It's rather interesting how parsing of variable length addresses was
> thought to be way too complicated - while parsing of IPv6 extension
> header chains of unknown length was okay.

variable length addressing was thrown out at the time because the OSI
model showed that it created a good deal of trouble for no overriding
benefit. Processing variable length addresses was found to be as
difficult as processing the longest length allowed.  In practice, NSAP
addresses were limited to 20 octets, but in theory they could be up to 255.

IPv6 extension headers, on the other hand, weren't considered a major
imposition at the time because almost all routers in the mid 1990s were
cpu switched rather than handled on asics.  Walking through TLVs is
relatively straightforward to handle from an algorithmic point of view,
but it creates pain when dealing with forwarding lookup engines because
extension headers means inspecting more header data when calculating the
next-hop when you're dealing with ECMP / LAGs. This is harder when
dealing with hardware/offloaded lookup engines because more header
information needs to be copied from the interface to the lookup engine,
which has a cost.  It's not insurmountable, just more expensive from a
hardware point of view, which means that lots of cheaper kit doesn't do
this well, or in some cases, at all.

Nick

Re: 1/2u 100g Metro-E Aggregation Switch

[Lewis,Mitchell T.]

Any further details on this? I haven't seen any press releases from Juniper. 



Regards, 

Mitchell T. Lewis 

[ mailto:mle...@techcompute.net | mle...@techcompute.net ] 


[ http://linkedin.com/in/mlewiscc ] |203-816-0371 

PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ 
https://pgp.mit.edu/pks/lookup?op=get=0x2AFA805732A1394E | Public PGP 
Key ] 



From: "Jerry Jones"  
To: "Luke Guillory"  
Cc: "Lewis,Mitchell T." , "NANOG"  
Sent: Friday, December 29, 2017 8:47:49 AM 
Subject: Re: 1/2u 100g Metro-E Aggregation Switch 

Wait for the ACX5448 coming soon. 


On Dec 28, 2017, at 11:13 PM, Luke Guillory  wrote: 

QFX5110-48S, 4x100 or 4x40 plus 48 SFP+ 




Sent from my iPad 

On Dec 28, 2017, at 10:50 PM, Lewis,Mitchell T. 
> wrote: 

Anyone know of any alternatives to the Ciena 5170 Service Aggregation Switch? I 
am looking for something that has 4 100g ports for metro ethernet in a 1/2u 
form factor. 



Regards, 

Mitchell T. Lewis 

[ mailto:mle...@techcompute.net | 
mle...@techcompute.net ] 


[ http://linkedin.com/in/mlewiscc ] |203-816-0371 

PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ 
https://pgp.mit.edu/pks/lookup?op=get=0x2AFA805732A1394E | Public PGP 
Key ] 





Luke Guillory 
Vice President – Technology and Innovation 


[cid:imaged86681.JPG@423db806.4c87add4]  

Tel: 985.536.1212 
Fax: 985.536.0300 
Email: lguill...@reservetele.com 
Web: www.rtconline.com 

Reserve Telecommunications 
100 RTC Dr 
Reserve, LA 70084 





Disclaimer: 
The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material which should not disseminate, distribute or be 
copied. Please notify Luke Guillory immediately by e-mail if you have received 
this e-mail by mistake and delete this e-mail from your system. E-mail 
transmission cannot be guaranteed to be secure or error-free as information 
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or 
contain viruses. Luke Guillory therefore does not accept liability for any 
errors or omissions in the contents of this message, which arise as a result of 
e-mail transmission. 

Re: Foundry FastIron

[Olivier Benghozi]

By the way, Foundry/Brocade small/campus switches were sold by Broadcom to 
Ruckus, not to Extreme (who bought the bigger switch/routers).

https://support.ruckuswireless.com/product_families/21-ruckus-icx-campus-switches
 


https://support.ruckuswireless.com/product_families/23-_eol-fastiron-products 


Of course, as it is an end of life product in their shopping bag, I wouldn't 
expect much :)


> On 29 dec. 2017 at 09:19, Mike O'Connor  wrote :
> 
>> A client of mine has some Foundry FastIron Edge X424HFs.
>> 
>> Brocade and Extreme don't seem overly ambitious to help.
>> 
> Brocade EOL'ed those old FESX-4 switches themselves on 03/31/2011, 
> with EOS in 2016.  This was before Brocadecom spun off to Extreme.

Wi-Fi Analyzer

[Bryan Holloway]

Curious if the community has any recommendations and/or positive 
experiences to share for a handheld Wi-Fi (802.11a/b/g/n/ac) analyzer.


Software/laptop-based solutions can be unwieldy in certain environments. 
However, given rave reviews, I'm open to the idea as long as it's 
Mac-compatible.


Should be able to show detailed spectra, help locate sources of 
interference, have mapping capabilities, etc.


Thanks!

Re: Waste will kill ipv6 too

[Mikael Abrahamsson]

On Fri, 29 Dec 2017, sth...@nethelp.no wrote:

It's rather interesting how parsing of variable length addresses was 
thought to be way too complicated - while parsing of IPv6 extension 
header chains of unknown length was okay.


I think this can be explained by "routers don't need to parse extension 
headers, they're routers, they only act on L3".


Some of the people around back in early/mid 1990ies involved in designing 
IPv6 is still around in IETF, you can always ask them.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: 1/2u 100g Metro-E Aggregation Switch

[Jerry Jones]

Wait for the ACX5448 coming soon.


On Dec 28, 2017, at 11:13 PM, Luke Guillory  wrote:

QFX5110-48S, 4x100 or 4x40 plus 48 SFP+




Sent from my iPad

On Dec 28, 2017, at 10:50 PM, Lewis,Mitchell T. 
> wrote:

Anyone know of any alternatives to the Ciena 5170 Service Aggregation Switch? I 
am looking for something that has 4 100g ports for metro ethernet in a 1/2u 
form factor.



Regards,

Mitchell T. Lewis

[ mailto:mle...@techcompute.net | 
mle...@techcompute.net ]


[ http://linkedin.com/in/mlewiscc ] |203-816-0371

PGP Fingerprint: 79F2A12BAC77827581C734212AFA805732A1394E [ 
https://pgp.mit.edu/pks/lookup?op=get=0x2AFA805732A1394E | Public PGP 
Key ]





Luke Guillory
Vice President – Technology and Innovation


   [cid:imaged86681.JPG@423db806.4c87add4] 

Tel:985.536.1212
Fax:985.536.0300
Email:  lguill...@reservetele.com
Web:www.rtconline.com

   Reserve Telecommunications
100 RTC Dr
Reserve, LA 70084





Disclaimer:
The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material which should not disseminate, distribute or be 
copied. Please notify Luke Guillory immediately by e-mail if you have received 
this e-mail by mistake and delete this e-mail from your system. E-mail 
transmission cannot be guaranteed to be secure or error-free as information 
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or 
contain viruses. Luke Guillory therefore does not accept liability for any 
errors or omissions in the contents of this message, which arise as a result of 
e-mail transmission.

Re: Foundry FastIron

[Mike O'Connor]

:A client of mine has some Foundry FastIron Edge X424HFs.
:
:Brocade and Extreme don't seem overly ambitious to help.

Brocade EOL'ed those old FESX-4 switches themselves on 03/31/2011, 
with EOS in 2016.  This was before Brocadecom spun off to Extreme.

:Anyone have any documentation they can scrounge up? SFP compatibility list? 
The ones I see in there already look substantially like the ones I get from 
FiberStore, but that doesn't mean much.

Can't help you there, sorry...  

:Do they still sell support on these? I'm largely just interested in newer 
firmware for them. I don't think they were updated since they left the factory 
and there are a few quirks I'm hoping they addressed at some point.

Depending on your bother, check out the FESX424-L3U "Layer 3 Upgrade
Kit".  That particular software piece looks like it gets support for
another few months, if I am to believe Brocade's website (which only
has the FESX-6 EOL notice, not the older FESX-4 one).

http://www.brocade.com/en/backend-content/pdf-page.html?/content/dam/common/documents/content-types/end-of-life-notice/brocade-fastiron-edge-x-6-end-of-life-notice.pdf

-Mike

-- 
 Michael J. O'Connor  m...@dojo.mi.org
 =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
"Take me out... to the black.  Tell 'em I ain't comin' back."-Firefly


signature.asc
Description: PGP signature

Re: Waste will kill ipv6 too

[sthaug]

> > My wild guess is if we'd just waited a little bit longer to formalize
> > IPng we'd've more seriously considered variable length addressing with
> > a byte indicating how many octets in the address even if only 2
> > lengths were immediately implemented (4 and 16.)
> 
> Actually, that got heaved over the side fairly early in the IPng discussion,
> because nobody  who was building silicon last century wanted to
> deal with arbitrary-length addresses.  The IPv4 header had source and
> destination addresses on 4-byte boundaries for good reasons which
> still held true when we did the IPv6 headers.

It's rather interesting how parsing of variable length addresses was
thought to be way too complicated - while parsing of IPv6 extension
header chains of unknown length was okay.

Steinar Haug, Nethelp consulting, sth...@nethelp.no