Re: I-D ACTION:draft-nordmark-multi6-noid-02.txt

[Erik Nordmark <Erik.Nordmark@sun.com>]

> 1. I am uncomfortable about the dependency on reverse DNS. It will
> effectively mean that only well-run servers can benefit from mh, because
> client systems with temporary addresses (especially RFC 3041 addresses) are
> realistically unlikely to have reverse DNS in place. And that probably
> eliminates mh for peer-to-peer applications too, which is a shame.

FWIW I have the same concern.
Given that the alteratives to using the DNS for verification have other
downsides I think we should explore how to make a hybrid using techniques
from HIP and WIMP to secure things when DNS is not usable.

> 2. I'd have liked to see a walk-through for a 3rd-party referral case (i.e.
> how would it work for p2p anyway?).

Makes sense to add that to the draft.

> 3. I am also uncomfortable about "the bit." The whole of section 6 is, well,
> a bit kludgy. The only clean solution IMHO is a shim header, which knocks
> 8 bytes off the user's MTU. In the catgeory of possible alternatives, we
> could in theory add
>   - encode a couple of bits in the flow label
>   - get back the ECN bits
> 
> (I'm not advocating either of these, but since the draft lists
> alternatives...)

I personally think an 8 byte extension header would be fine.

(Re)using existing bits in the flow label or ECN for this isn't possible
since you'd need some indication in the packet whether the new or the old use 
is intended, hence you need at least one bit somewhere else.

  Erik