Subject: RE: Proxy ND?

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 10 Mar 2003 10:22:38 -0800

Pekka,

> 
> On Sun, 9 Mar 2003, Mohan Parthasarathy wrote:
> > > On Sun, 9 Mar 2003, Jari Arkko wrote:
> > > > Interesting idea. In a way, this happens when the router and the
> > > > first node are upgraded to SEND: everyone else sends their ND
> > > > packets to the router, and all communications of the one SEND
> > > > node come through the router. The SEND node believes it is the
> > > > only node on the link. The other nodes are not on the link,
> > > > and ND is not used for communicating with them. Just like
> > > > any other node in the Internet.
> > > 
> > > Yep.
> > >  
> >
> > I am a bit confused by this. If "L" bit is set in the RA, then all
> > nodes will think all other nodes covered by that prefix is on-link.
> > In that case all nodes on that link covered by that prefix
> > will send the advertisements to solicited node multicast address of
> > the target node directly i.e how do you make the nodes send 
> the ND packets
> > to the router ? It would work if one never sets the L bit 
> in that case.
> > But as the SEND hosts increase, you may want them to 
> communicate directly
> > rather than through the router.
> 
> The neighbor solicitations are sent to the solicited-node multicast 
> address.  However, the on-link target node will not respond 
> to them: it 
> will not even see them (because they're protected by AH and 
> the target 
> node can't verify AH).
> 
Agreed. 

> This could be worked around by e.g.:
> 
> Modify the ND prototocol so that in the case of SEND:
>  1) solicits are sent to all-nodes multicast address, or

This requires the changes to the existing protocol, which may not be in
the scope of the WG.

>  2) the SEND router also joins all solicited-node multicast 
> addresses for 
> non-SEND nodes so it can see the solicitations

Or listen for all multicast packets (like multicast router) which is more
realistic to me. There are 2 cases :

1) ND packets coming from non-SEND nodes to SEND nodes. SEND node will drop
   the ND packet as it is not protected. The router will pick up this
   packet and it needs different set of IPsec processing rules i.e it needs
   to know whether the node that sent the ND packet is non-SEND or SEND.
   Assuming it accepts the packet, either it may have to initiate a NS
   (as it may not have neighbor cache entry) and then respond or directly respond.

2) ND packets coming from SEND nodes to non-SEND nodes. Non-send nodes will drop
   the ND packet as it is protected. The router will pick up this packet and
   sends the response directly or after querying the non-SEND node. 

From what i can understand, this seems to require some additional state to be
maintained as the router itself may not have the required neighbor cache entry.
If you don't want to maintain state, then the response needs to be multicasted.
And, i am still not clear on how you will configure the IPsec SPD entries on the 
SEND router. 

-mohan

> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------