Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.txt

From: "Bound, Jim" <[email-masked]>
Date: Tue, 24 May 2005 10:44:37 -0400

Brian and authors,

My response below.  Thus I cannot support this going to the IESG without
further discussion as my input. I also support Margaret's request for
this to be checked by RTSP persons, and I realize Dave T. clearly has
this expertise but it is a good logic check. Unless we want to remove
RSTP.  I think we should include RSTP but it needs more review.

General Comments:

I also would like to see this work not focus at all on IPv4 and only
address IPv6. The IPv4 work should be a separate document completely.
To permit this behavior for prefixes to span links in IPv6 is a
significant change to one of our architectural precepts for IPv6 and
cannot be considered lightly, regarding link behavior. 

Because it is an informational document I do not ask for implementation
but it would be good to suggest this somewhere in the spec.  If it were
going to PS then implementation in this case is example where I think
the IETF has to ask for that as it could negatively impact current and
future deployment of IPv6.

I would like to see a third scenario that aligns better with section 4.
The two presented are ok but depicting two links with proxy between as
in section 4 would be good scenario to add.

I think DHCPv6 needs to be addressed when in use by the client and is
missing in the discussion.

Specific comments below:

From 

>3.1.  Non-requirements

>The following items are not considered requirements, as they are
>not met by classic bridges:

>  The following additional items are not considered requirements for
>  this document:

>o    Support Neighbor Discovery, Router Discovery, or DHCPv4
>    packets using IPsec.  We also note that the current methods
>   for securing these protocols do not use IPsec so this is
>    considered acceptable.

That IPsec will not be used or is not being used for ND is simply not
valid or true. This may be an opinion or state for deployment by the
authors but it is certainly not the view of all regarding deployment.
Thus IPsec must be addressed if it is used and a statement what this
means to the ndproxy proposal.  I feel this is a hard requirement.  This
shows up again below as issue for me indirectly.

From

>4.  Bridge-Like Proxy Behavior

>As with all other interfaces, IPv4 and IPv6 maintain a neighbor
>cache (aka "ARP cache") for each proxy interface, which will be
>used as described below.  For readability, we will describe the
>neighbor cache as if both IPv4 and IPv6 neighbors use the same
>state machine described in [ND].

That is not good to state IPv4 can use same abstraction as ND and gives
the wrong impression to a reader.  It simply is not true for most
implementations.  But, I would like IPv4 removed from this spec.  The ND
spec clearly documents the diffs and they are great enough to even
compare or identify in this manner is not prudent in a specification.

>4.1.3.3.  DHCPv4 Packets

Need section on DHCPv6.

>4.1.4.3.  ICMPv6 Router Advertisements

>If an RA with the P bit set has arrived on a given interface
>(including the upstream interface) within the last 60 minutes,
>that interface MUST NOT be used as a proxy interface; i.e., proxy
>functionality is disabled on that interface.

The Proxy is acting as a router and this requirement for a P bit does
affect router implementations and that was a non goal.  This is a
discrepancy and if the Proxy is a router it needs to adhere to that
which a router must do and that needs to be added to  the spec
somewhere.

>4.2.  Originating Packets

>P receives the solicitation (since it is receiving all link-layer
>multicast packets) and processes it as it would any multicast
>packet by forwarding it out to other segments on the link.
>However, before actually sending the packet, it determines if the
>packet being sent is one which requires proxying.  Since it is an
>NS, it creates a neighbor entry for A on interface 1 and records
>its link-layer address.  It also creates a neighbor entry for B
>(on an arbitrary proxy interface) in the INCOMPLETE state.  Since
>the packet is multicast, P then needs to proxy the NS out all
>other proxy interfaces on the subnet.  Before sending the packet
>out interface 2, it replaces the link-layer address in the SLLA
>option with its own link-layer address, p2.

This a routing function though a proxy and do we want to add this
function to router requirements.  This also has security issues that
could cause DOS and affect data integrity of the network configuration
parameters.  

>6.  Loop Prevention

>Loop prevention using RSTP would typically be done by devices that
>already implement this protocol as a result of supporting normal
>briding functionality, and is done here as follows.  IEEE 802
>interfaces use the protocol exactly as specified in [BRIDGE].
>Operation of RSTP over other types of link layers is done by
>encapsulating the RSTP frame in an IPv6 header.  The Next Header
>field is set to [TBA by IANA], indicating that an RSTP header
>follows.  The Destination Address field is set to the Link-scoped
>RSTP Multicast Group [TBA by IANA].  All proxies operating on non-
>IEEE 802 media join this group so they will receive RSTP packets.
>RSTP packets are never forwarded or proxied.

Now packets are being added for NH and DST options and that needs to be
checked if it is the best method to perform this function.  It might be
better as hop-by-hop option rather than DST option as thought.  This
should all be checked with RTSP WG in IETF.

>Loop avoidance using the P bit in RAs is done as follows.  The
>proxy determines an "upstream" proxy interface, typically through
>a physical choice dictated by the scenario (see Scenarios 1 and 2
>above), or through manual configuration.  As described in Section
>4.1.3.3, only the upstream interface is allowed to receive RAs,
>and never from other proxies.  Proxy functionality is disabled on
>an interface otherwise.  Finally, a proxy MUST wait until it has
>sent two P bit RAs on a given "downstream" interface before it
>enables forwarding on that interface.

We have now used up precious bit space in ND and I do not see the
justification unless we open this concept to working with general router
implementations and that is what the proxy is in my view.

>7.  Guidelines to proxy developers

This should be appendix not part of the specification.  It is conjecture
and suggestion that is all.

>9.  Security Considerations

The security section is fair assessment but assuming SEND is not valid
and many of us have many issues with SEND including but not limited to
IPR, interface with PKIs, and that it does not assist with
identification of the node on a wireless network.  NDproxy now permits a
rogue node to not only attack one link but now multiple links via the
Proxy and thus exacerbates the entire problem we have with stateless
wireless nodes in general. This needs to be added to the current list of
security section.  In addition I would like to see a softer support that
SEND solves anything and a TBD.

thanks
/jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Brian Haberman
> Sent: Tuesday, May 24, 2005 7:40 AM
> To: IPv6 WG
> Cc: Bob Hinden
> Subject: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.txt
> 
> IPv6 WG,
>       This begins a 1-week Working Group Last Call on advancing:
> 
> 	Title		: Bridge-like Neighbor Discovery 
> Proxies (ND Proxy)
> 	Author(s)	: D. Thaler, et al.
> 	Filename	: draft-ietf-ipv6-ndproxy-02.txt
> 	Pages	: 20
> 	Date		: 2005-5-23
> 
> as an Informational document.  Substantive comments should be
> directed to the mailing list.  Minor comments and editorial issues can
> be sent to the editor.  This last call will end on June 3, 2005.
> 
> We also request that people comment on their support or opposition
> to advancing this document.  There has been mixed public support for
> this work and it cannot advance without consensus from the working
> group.
> 
> Regards,
> Brian & Bob
> IPv6 WG co-chairs
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Tim Chown <[email-masked]>
Date: Thu, 26 May 2005 10:39:18 +0100

> RSTP.  I think we should include RSTP but it needs more review.

This seems sensible.
 
> cannot be considered lightly, regarding link behavior. 

An interesting point is made in the last para of 1.1, that if PD is used
with an existing IPv4 ARP proxying scheme, you may get multiple IPv6
links delegated with one IPv4 subnet, and some potential complications.  
But I agree that a compromise for IPv6 to cater for IPv4 is a debatable 
issue.   Also, I'm not sure that ISPs charging for multiple prefixes 
(whether they will or not) and the payment issue needs to be in here?
 
As an aside, I feel the introduction is missing something (and maybe this
is linked to Margaret's scoping question) - para 1 talks of "the problem"
and para 2 of a "common solution" but the problem isn't stated in the
main text (the abstract implies it :).

-- 
Tim/::1