Date: Tue, 2 Jul 2002 11:40:45 -1000
From: "Chang, Ellen" <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| I have few questions related to IPv6 specs. Can anyone please help me to
| clarify them?
These are just my opinions, but by offering them, if they're wrong,
someone who knows better will contradict, and probably even supply
references to the specs...
| 1. If a IPv6 node A send an Echo Request with destination option or
| hop-by-hop option to IPv6 node B, should the node B respond an Echo Reply
| with the options OR without the options?
I think that very much depends upon the options. Options get processed
by the IP stack, regardless of the upper protocol selected (including the
special case of echo). Whatever they indicate should be done, should be
done - if that means sending something back in the next packet that goes
back to the source, then that's what would happen.
Certainly there's no rule that says that options have to be sent back as
they were received, in any packet, including echo reply - for some options
that might exist, that would be incorrect.
| 2. If a IPv6 node A send a Packet with multiple same routing headers to
| IPv6 node C through IPv6 node B, should the node B only process the first
| routing header (update the dst address, routing segments left and address)
| before it propagate the packet to IPV6 node C, OR should the node B process
| all the routing headers? If the node only process one of the routing
| header, would it cause interoperability problem ?
Just the first. As soon as a node receives a packet (by which I mean,
the dest address in the IPv6 header is the node's address, rather than
just "it appeared at my interface") and finds a routing header that isn't
exhausted, it does the routing header address swap, and forwards the
packet (or decides that forwarding packets isn't its function in life,
and discards the packet, of course). It never looks beyond that routing
header, so would never see a later one.
As I understand it, including multiple routing headers is still something of
a "who knows what that might be useful for or what it means" area - that is,
nodes would be strongly advised not to do that.
My take on what to do if a node receives a packet with an exhausted routing
header, is just to go on to look at later headers (that I think is clear).
If it then finds another routing header, which isn't exhausted, it would
just process it as normal (that is, the already exhausted routing header it
passed over wouldn't alter things at all - that part is my opinion).
The effect would be that two consecutive routing headers would be just the
same as one larger one that is the concatenation of the two (which might be
useful occasionally if one is needed that is bigger than is possible, which
isn't very likely one hopes). A more likely reason would be when one
desires to include options to be processed at some routers along a path.
An options header between routing headers would get processed only by
routers after the first routing header is exhausted (but then by all after
that). It isn't beyond the bounds of possibility that someone might
create an option which says "remove this option and all before it in this
header, then skip any other options in this header". With an option like
that more selective processing of other options could be managed.
(The "remove" could be done by overwriting with NOOP of course).
| 3. If a IPv6 node A send an Echo Request with unrecognized options( and
| their highest-order two bits set to 00) to IPv6 node B, should the node B
| respond an Echo Reply without the unrecognized options from the Echo
| Request, OR should the node B respond an Echo Reply with the unrecognized
| options? Or are both ways acceptable?
Without I'd say.
| 4. If the neighbor solicitation message has the global address as its source
| address, does it consider to be an valid message ?
No. NS packets come from LL addresses. Anything from any other kind of
address is an error, and should be ignored.
| 5. If a NPv6 node A send an Router solicitation message to IPv6 node B,
| should the node B respond an Router advertisement with invoking router
| solicitation message's source address as it's destination address, OR the
| node B allow to send Router advertisement with multicast destination
| address.
The multicast address. And I think it isn't "allowed" but must. That's
what prevents RS/R Astorms when a labfull of nodes all boot. They all
delay their RS by a random interval. One of them (naturally) has the
shortest random interval. That one sends its RS (assuming chance hasn't
caused a RA to appear in the meantime). Routers that receive it all
send RA's to the multicast addr. All the other nodes receive those RAs
and so never send an RS.
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]
--------------------------------------------------------------------
