IPv6 RA vs DHCPv6 - The chosen one?

Wed Dec 28 12:01:37 UTC 2011

Your straw man argument (which is what this has become) is just
dancing around the real issue.  You're going to have to back up and
make your case for us, rather than trying to respond to one-liners
made (most of which were sarcastic, by the way).

You have yet to identify who (beyond yourself) is calling for RA to be
deprecated, though you made it sound like majority of the IETF was.

You have yet to identify the problems with the design of RA that
support that assertion.

Taking the position that a single statement "is not a valid counter
argument against a proposal to make RA deprecated" is weak at best; in
actuality it wasn't a counter argument at all, but rather a statement
exposing that you haven't presented an argument yet.  The burden of
proof lies with you, as you're the one calling for the deprecation of
RA.

So let's hear that, please (genuinely interested).

2011/12/28 Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>:
> Valdis.Kletnieks at vt.edu wrote:
>
>>> IPv6 does not work well in many environments.
>>
>> Feel free to try to deprecate *everything* that doesn't work well in many
>> environments.
>
> Why not?
>
>> Heck, SMTP doesn't work well in many environments (it's done in
>> cleartext unless you deploy STARTTLS, it's subject to spamming, etc etc)
>
> Red herring.
>
> I thought all of us on some mailing list recognize SMTP working
> well.
>
> But, if you insist you don't, feel free not to use it, which means
> you leave most, if not all, mailing lists including NANOG ones.
>
>> It's one thing to deprecate something that's obviously a complete failure or
>> has reached historic status - but RA isn't either of those *yet*.
>
> That is not a valid counter argument against a proposal to
> make RA deprecated, that is, make RA reach historic status.
>
>>> In this case, the following statement in RFC1883:
>>>>    If the minimum time for rebooting the node is known (often more than
>>>>    6 seconds),
>>> is the wrong assumption which made RA annoying.
>>
>> Oddly enough, a lot of us are running on networks where assuming this about end
>> user gear is perfectly reasonable.
>
> That is because, as I wrote already in the previous mail,
>
>>       Network configuration was mostly stationary
>
> For example, IPv6 might work well, if most of your end users
> are not moving rapidly between small mobile cells.
>
> However, assuming you change the cells every 100m in average
> and you are moving at 100km/h, you must change the cells every
> 3.6 seconds in average, which means you must be able to change
> the cells frequently, which means each cell change take a lot
> less than 3.6 seconds.
>
>> We haven't seen many consumer-grade
>> Windows, Macs, or Linux boxes that are able to reboot in much under 6 seconds.
>
> IPv6 is wrongly architected, not because it assumes nodes are
> able to reboot in much under 6 seconds, but because it assumes
> new configurations necessary only at boot time.
>
>> Yes, I know you can do it with careful tuning and throwing SSDs and other
>> hardware at it - doesn't mean it's common.
>
> Obviously, the IPv6 committee and you are assuming computers
> of immobile main frame computers or, at least, immobile
> workstations.
>
> However, in the real world, commonly available mobile phones
> are IP capable computers which wake up from dormant state
> within a second and needs handover often within a second.
>
>                                                Masataka Ohta
>

-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/