Re: Moving PIC forwards

[Jari Arkko <Jari.Arkko@xxxxxxxxxxxxxxx>]

>One cause of the fragmentation problem is PPPoE.
>...
>But v6 doesn't even have router-based fragmentation, so 
>we may want to plan ahead
>...

Fragmentation as such isn't sufficient to cause a
problem. You also need a firewalling router or
something like that to drop all fragments packets,
because they weren't programmed to deal with
that. IPv6 still allows up to 2^16 (or even 2^32)
bytes long UDP packets. The place of the fragmentation
is different, though, it's e2e.

But let's turn back to Bernard's original problem.
He said "I'd like the protocol to run over TCP, so
that we can handle large certificate payloads without
fragmentation. In practice, fragmentation of
IKE cert payloads has turned out to be a headache..."

So, let's assume our setup is (a) PIC to node 1 in
a corporate network followed by (b) IKE+IPSEC
to a node 2 in a corporate network. PIC has long
payloads, and so does IKE where certs are used.
Then we also assume there's a broken router somewhere
that doesn't do fragment filtering correctly. So,
what would be the effect of providing improved
TCP PIC? Step a could then be accomplished, but
no communication could be established because
Step b would break at the router.

In conclusion, it seems that TCP PIC isn't useful
until IKE runs over TCP too. In the mean time
we have to ensure our routers and firewalls
do the right thing. TCP PIC doesn't help.  But,
Bernard, is the problem the same in PIC as it is
in IKE cert payloads, or is it bigger? If we rarely
hit the problem in IKE but would hit it all the time
in PIC, then it might make sense think more about it.

Jari