Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation]

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 13 Feb 2002 19:39:35 +0100

=> Can you show one example for 'whatever means'?
The reason I'm asking is that it has been mentioned
by several people that the issue here is 
authorisation. Currently the only methods we know 
of that would guarantee the required levels of 
authorisation are : RR and RR+CGA. Possible 
alternatives:

- PKI with addresses inside? didn't think this 
  is an option
- AAA? This adds more burdens (infrastructure
  requirement and inflexbility)
  I'm trying to keep it short but the details 
  were all discussed in the last 2 weeks.

  > RR is proposed as a scalable solution that can support
  > billions of nodes.  I would be very opposed to any
  > attempt to shape every other bit of protocol around
  > this interim solution.

=> I don't know why you think it's interim. 

  > 
  > >    Something like BU3WAY runs the entire protocol
  > >    on ICMP, so you can't piggyback these meesages
  > >    anyway. Where is the issue?
  > 
  > This is totally irrelevant to what happens when you
  > already have an established security association that
  > enables use of Binding Update with payload.

=> See above.

  > >   > That is a very important point.  Regarding the "asserted"
  > >   > benefits, I think it can be shown that piggybacking _always_
  > >   > offers performance benefits to a compliant IPv6 
  > implementation,
  > >   > and that sometimes the benefits would enable important
  > >   > applications (like voice) to work better.
  > >
  > > => Interesting, because I can negate the exact
  > > argument with examples.
  > 
  > If so, then I will be able to show that your examples
  > are not IPv6 compliant.

=> Charlie, this argument does not hold. Using
extension headers is useful for processing
of the 'received' packets. It doesn't mean
that we can put any protocol into any packet and
that disallowing this breaks IPv6. It might 
be worth discussing this on the IPv6 list
though.

  > >   > There are not any such links that correctly implement IPv6
  > >   > MTU.
  > >
  > > => What does this mean?? There are no link layers
  > > that follow RFC2460?
  > 
  > Of course it does not mean that.  It means that link layers are
  > required to handle MTU >= 1280, and Binding Updates with
  > average payloads fit well within that requirement.  

=> 'Fit well' depends on the size of the packet without
the BU.

I cannot
  > imagine how you might have constructed the interpretation in
  > your second sentence.

=> It seemed like you said: there are no such links 
that correctly implement IPv6 MTU.

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 13 Feb 2002 10:58:35 -0800

Hello Hesham,

Continuing...

> => Can you show one example for 'whatever means'?

How about manual configuration?  Every mobile node
should be allowed to establish a permanent security
association by manual configuration.  The argument
against this for billions of correspondent nodes is clear.
There isn't any good argument for disallowing it in
special cases.

I also think it is clear that protocols will be developed
for long-term key establishment that do not depend on
bu3way or RR, although I like RR methods myself.
Any long-term association will serve for this example.

>   requirement and inflexbility)

There's a huge difference between mandating AAA for
all purposes (which would be hard because of the reasons
you have given) and disallowing it for all applications
(which would be bad, because many scenarios work well
with AAA-style authorization).  AAA (and others!) could
be used to establish longer-term security associations
than ephemeral RR.

> => I don't know why you think it's interim.

O.K.  Even if it's permanent, other solutions will be devised.

> be worth discussing this on the IPv6 list

This discussion about piggybacking is ONLY relevant for
received packets, and already IPv6 essentially mandates that
receivers be able to to the appropriate processing for IPv6
extension headers.  There is NO requirement that a sender
has to use piggybacking.

When I read this sentence:
              It doesn't mean that we can put any protocol
              into any packet and that disallowing this breaks IPv6.
I start to think that you are absolutely not following my
discussion.  But to try to make it clear:
- IPv6 nodes MUST be able to transmit packets with MTU >= 1280
- IPv6 nodes MUST be able to parse certain extension headers.
Putting these two mandates does not in any way add up to
"putting any protocol into any packet".  I think you should try to
explain why you made that characterization.

> that correctly implement IPv6 MTU.

The links that you claim, are links that do not correctly implement IPv6.
There are no links, such as you claim, that correctly implement IPv6.
There are plenty of links that correctly implement IPv6.  These links
are not of the variety that you claim exist.  I don't know what else I can

say to make this clearer.

Regards,
Charlie P.