Re: [CARD Editorial Issue] IANA Considerations Section

"James Kempf" <[email protected]>
Newsgroups gmane.ietf.seamoby
Message-ID <00cf01c340b1$d2cdaf30$636015ac@dclkempt40>
> >In general, ICMP messages do not have options. Messages that are part of
> >Neighbor Discovery (RFC 2461/62) ICMP messages do have options, however.
> >
> >
> Fast-MIPv6 messages are ICMP-style as well, and they carry options.
>

Please show me in RFC 2463 where general ICMP messages are allowed to carry
options.

RFC 2461 does define options for the specific case of neighbor discovery
ICMP messages, in Section 4.6. And, I believe the RtSolPr/PrRtAdv messages
are intended to be a subset of those messages.

> >In this case, there is no need for IETF concensus to assign suboption
types
> >to a new ICMP message. They can just be assigned in the draft.
> >
> >
> This is right assuming the case to keep CARD protocol operation
> stand-alone. In case of carrying
> CARD protocol messages as options with the Fast-MIPv6 RtSolPr ot PrRtAdv
> respectively,
> there should not be a conflict in options' types.
>

So does RFC 2461 say that IETF concensus is required to assign option
numbers for ND options?

            jak
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.