Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#25 closed defect (fixed)

MN-AR interface specifying REDIRECT behavior

Reported by: julien.ietf@… Owned by: julien.ietf@…
Priority: major Milestone:
Component: draft-ietf-netlmm-mn-ar-if Severity:
Keywords: Cc: netlmm@…

Description

Having the AR redirect a MN to another MN which happens to be on the same link is problematic because if one the MN subsequently moves off-link but still in the NetLMM domain there will be no way for ARs to have either of the MN sending packet directly to their correspondent to send them via their AR.

Proposed Resolution: Specify that an AR SHOULD not redirect MNs for on-link destinations.

Change History (6)

comment:1 Changed 13 years ago by julien.ietf@…

  • Cc netlmm@… added

comment:2 Changed 13 years ago by julien.ietf@…

  • Resolution set to fixed
  • Status changed from new to closed

Fred Templin wrote:

One attribute of a multi-link subnet (which I think should be agreed that NETLMM is an example) is that MNs in the same IP prefix may be attached to different links. Moreover, MNs that were formerly attached to the same link may move to different links during the course of communication sessions.

So, I can see reason for the MN-AR interface spec to supercede the normative reference but only if it gives a specific reason for doing so, e.g.,

"An AR SHOULD NOT send a redirect message ([RFC2461], Section 8.2)

unless it can determine that the sending node and better first-hop node reside on the same link and will remain on the same link."

Resolution: adopt the proprosed text.

comment:3 Changed 13 years ago by julien.ietf@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:4 Changed 13 years ago by julien.ietf@…

  • Cc netlmm@… added; netlmm@… removed
  • Resolution set to fixed
  • Status changed from reopened to closed

Fred Templin wrote:

One attribute of a multi-link subnet (which I think should be agreed that NETLMM is an example) is that MNs in the same IP prefix may be attached to different links. Moreover, MNs that were formerly attached to the same link may move to different links during the course of communication sessions.

So, I can see reason for the MN-AR interface spec to supercede the normative reference but only if it gives a specific reason for doing so, e.g.,

"An AR SHOULD NOT send a redirect message ([RFC2461], Section

8.2) unless it can determine that the sending node and better first-hop node reside on the same link and will remain on the same link."

Resolution: Adopt the text above.

comment:6 Changed 13 years ago by julien.ietf@…

On Wednesday 31 May 2006 17:52, Templin, Fred L wrote:

4.4.x. Forwarding Packets

An AR SHOULD NOT forward packets sent by a MN to a link-local address.

This might not square with the way link-local *multicast* will be handled in the multi-link subnet NETLMM world. AFAICT, the subject of multicast for NETLMM has not been explored yet in any detail and as such I am not aware of any consensus on that.

Do we know what the behavior should be for link-local multicast, i.e., should they stay only on the local link or be forwarded to all links in the NETLMM domain? If we don't know yet, then the safer thing to say at this time is: "An AR SHOULD NOT forward packets sent by a MN to a link-local unicast address."

On Thursday 01 June 2006 10:32, Julien Laganier wrote:

Fred,

My feeling is that NetLMM or not, a link is a link.

Even if one can see NetLMM as providing a kind of subnet emulation on multiple links, we are not bridging links together (that would be below the network layer.)

Hence my opinion is that NetLMM should not change the fact that link-locals (unicast or multicast) are confined to the link they originate from. This would be consistent with the IPv6 addressing architecture (RFC4291) which states that:

Routers must not forward any packets with Link-Local source or destination addresses to other links.

and:

Link-Local multicast scope spans the same topological region as the corresponding unicast scope.

On Thursday 01 June 2006 17:46, Templin, Fred L wrote:

Julien,

I think I can buy this rationale. It further clarifies the point that we are glueing together multiple links at the IP layer, i.e., multi-link subnet. Based on this, maybe the text should just cite the RFC4291 passages directly, but I'm OK either way.

Resolution: add the subsection below to the document.

4.4.3. Forwarding Packets

[RFC4291] states that:

Routers must not forward any packets with Link-Local source or destination addresses to other links.

Link-Local multicast scope spans the same topological region as the corresponding unicast scope.

This specification does not modify that behavior, i.e. an AR MUST NOT forward packets sent by a MN from or to a link-local address (unicast or multicast.)

Note: See TracTickets for help on using tickets.