Date:        Wed, 25 Jul 2001 11:22:15 -0400 (EDT)
    From:        Radia Perlman - Boston Center for Networking <[EMAIL PROTECTED]>
    Message-ID:  <[EMAIL PROTECTED]>

  | 2) The argument in favor of a hop-by-hop checksum is that you can
  | pinpoint the router that has the flaky memory that corrupts packets
  | in memory.

Does anyone actually do that?   Implementations I have seen just
count'em and ditch'em.   That is, if they check at all, I have heard
rumours of some that don't bother checking (just do the incremental
update for the TTL decrement).

  | 3) If, as Robert Elz says (and I'm not disagreeing), nothing in the layer 3
  | header needs to be protected,

That's not quite what I said - or not quite what I meant anyway.   What
I meant was that it doesn't need to be protected along the path.  That is,
if the dest IP address goes bad, the packet will be delivered to some random
node (or for IPv6 most likely not delivered at all).  In the first case the
pseudo-header checksum will catch it, in the latter the packet is discarded
anyway.

AH is end to end - detecting that the packet delivered to you is what was
sent can be valuable.   What isn't really needed is for that to happen at
every hop along the path - the number of header checksum errors (which
if undetected will cause some extra packet forwarding) is so small that
avoiding the extra stray forwarding isn't worth it.

The fields that AH doesn't cover are those that are only there to support
getting the packet to the destination, once it has safely arrived, they're
trash anyway (TTL, flow label, ...)   By no coincidence they're also the
mutable ones.

However, AH does assure us that the packet did come from who it claims
to be from, etc.

  | 4) Anyone know why I seem to be receiving 3 copies of every packet sent
  | to IPng?

There's some host in Korea forwarding everything sent to the list back to
it again.   It is most likely only the hop count eventually being
exceeded (fortunately the Received headers remain intact throughout)
that is preventing there being hundreds of copies of every message...

kre

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to