Hello,
Few comments on draft-thaler-ipv6-ndproxy-00.txt.
CP
1. Section 1. First bullet following the first paragraph.
The first bullet talks about an "access point". Give a reference to
the 802.11 spec. Should 802.11 be mentioned in the first place? What
advantage does ndproxy provide over classical bridges in an
802.11 network?
2. Section 1. 2nd Paragraph.
Rephrase to:
It is expected that whenever possible links will be bridged at the
link layer using classic bridge technology.
Bridging at the network layer SHOULD be used only when the classic
bridges cannot be used. For bridging at the network layer, a single
"bridge" interface will be exposed to the IP layer. In the
remainder....
3. Remove the reference to MLSR, the document is no longer present in
the I-D directory.
4. Section 1.
The explanation about the simple RA proxy is unclear. The terms
"downstream link" and "upstream link" are unclear. I started of with
the assumption that the upstream link refers to the bridge segment to
which the router is connected, and the downstream link is another
segment to which the RA's are to be forwarded. But then I could not
understand the problems caused. This approach needs some elaboration.
Appendix section seem to be the correct place holder for alternate
approaches. In other parts of the document, they distract the
reader.
5. Section 1.1.
Remove the line -> "It should appear as if one host uses multiple
addresses." It does not seem to add anything more that what is
specified in the previous sentence. In addition, it is semantically
incorrect. The router will never see the bridged hosts, as one
single host with multiple addresses.
6. Section 1.1
Remove the sentence starting with "If, on the other hand, neighbor
...". This sentence refers to implementation, and it is too early
in the document to do so.
7. Section 1.1
Add the following requirements.
a) Allow dynamic addition/removal of proxies, and nodes to the
network without disrupting traffic.
b) The proxy should be able to interwork with a 802.1d compliant
bridge.
8. Section 1.2
Rephrase the first requirement to
"Should not require assignment of an IP address. It implies that the
bridge will not be visible in traceroute scans."
9. Section 1.2 4th bullet.
Rephrase to:
Transparently support different MTU's in use on different segments.
The rest of the text should be moved in another section.
<Please refer to the other mail on suggested text>
10. Section 2. 4th Paragraph
The IPv4, and IPv6 implementation in the proxy is not going to
complete. I also can't think of the usage of the various neighbor
cache states in the proxy, and moreover, it cannot be implemented
as is.
<In my other email, I propose a simplified neighbor cache that can
be implemented in the proxy.>
11. Section 2. 5th Paragraph
What about processing of DHCPv6 packets? Don't they carry hardware
(link-layer) addresses?
Thinking a bit more about "packets that will need address
substitution" issue - providing a set of guidelines will help
implementors in deciding whether the link-layer address in the
payload of a protocol should be substituted by the link-layer
address of the proxy will help.
Such guidelines will also take care of future protocols, and this
document will not have to be updated.
My view of the guidelines is:
1. If the link-layer address in the payload of the protocol can be
used in the link-layer header of future messages, then the
proxy should substitute it with its own address. For example
the link-layer address in NA messages is used in the link-layer
header for future messages, and, hence, the proxy substitutes
it with its own address.
For broadcast/multicast packet the link-layer substituted
within the payload will be different for each outgoing port.
2. If the link-layer address in the payload of the protocol is
never used in the link-layer header, then the proxy should not
substitute it with its own address. In this case, the
link-layer address maybe included in the protocol payload to
uniquely identify the node. For example, link-layer address in
DHCPv4 messages is not substituted by the proxy, as that address
is never used in the link-layer header of any future messages.
3. All messages with unspecified IPv6/IPv4 destination address
should be broadcast on all ports.
15. Section 2. 13th paragraph.
Following the above guidelines will not require modification of
the BROADCAST flag in the proxied DHCPv4 packet. (I might be
mistaken, I have yet to confirm this with the DHCP specs)
16. Section 2. 8th paragraph.
Maintaining the same states in the neighbor cache as those in a
node is not correct. The proxy will not implement the node
procedures, and will not do state transitions in the same
manner. IMHO, more light needs to be shed on the subject. <I have
proposed a state transition table for proxies in my other email>
I also propose adding the following text : If a unicast message is
received for a destination for which there is no entry in the
neighbor cache then the message has to be forwarded on all
segments.
17. Section 2. 10th paragraph
Issues that may be encountered during address substitution should
be mentioned. They might seem obvious, but a mention will help the
developers.
One issue that I can think of is :
1. The link layer address will be new, and might have different
length. The new link layer address will result in
re-computation of certain parts of the IPv4/IPv6 header.
18. The proxy peeks inside certain messages, and replaces the
link-layer address with the link-layer address of the proxy. It is
not clear however the link-layer address of which port is
chosen. It seems that it will be the link-layer of the outgoing
port. This one needs some clarification.
18. Section 2. 6th paragraph
This paragraph defines the working of the proxy when "any other"
broadcast or multicast packet is received. It is mentioned that
the packet "is forwarded unchanged out all other proxy interface
on the same link".
Text needs to be added about how the message the packet is
forwarded on interfaces on other links.
19. Section 2. 12th Paragraph
What is the advantage of clearing the Override bit?
Some of the comments might not be relevant if the document is
reorganized.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
