Subject: My positions on pending items 6, 8, 11, 17, 19, 23

From: Ted Lemon <[email-masked]>
Date: Sat, 15 Feb 2003 21:27:47 -0600

Before I state my positions, I should say that I've heard and 
understood the various opinions that have been presented on these 
issues, so in particular there is no need for Kevin or kre to send me 
additional messages explaining their respective points of view.   I 
have sympathy with both their positions and respect them, but I think 
some of my positions disagree with theirs.   Reasonable people may 
differ on these points.

LL6:   We shouldn't add the suggested text.   The theory is that IPv4ll 
creates a new vulnerability because a node that has a wireless 
interface could be attacked in cases where this was not previously 
possible.   This theory is not correct because there is no case where 
an attack via IPv4ll would have been possible in which an attack via 
DHCP would not also have been possible.   If a warning like the one 
suggested needs to go anywhere, it needs to go in the 802.11 and 
bluetooth standards, not in this draft.   Adding the proposed text 
implies that there is a problem with wireless networking that is 
specific to IPv4ll, when there is no such problem.

LL8: The text imposes some implementation requirements that don't make 
sense, because the implementor has no way of knowing whether or not a 
particular node is a router.   This text should be removed:

> section 2.6
> If the destination address is in the 169.254/16 prefix ...
> The host MUST NOT send the packet to any router for forwarding.
>
> [...]
> The host MUST NOT send the packet to any router for forwarding.
>

This text should be replaced:

> section 2.7
> An IPv4 packet whose source and/or destination address is in the
> 169.254/16 prefix MUST NOT be sent to any router for forwarding, and
> any network device receiving such a packet MUST NOT forward it,
> regardless of the TTL in the IP header.

With this:

> section 2.7
> Any network device receiving an IPv4 packet whose source and/or 
> destination address is in the 169.254/16 prefix  MUST NOT forward it, 
> regardless of the TTL in the IP header.

I should say that I am not going to withhold my participation in 
consensus based on whether this advice is followed - if the text is 
left as is, I don't think it does a lot of harm, but it's technically 
incorrect, and could conceivably lead someone to waste a lot of time 
trying to figure out how to implement it.

LL11: I agree that the proposed new text is better than the old text.   
However, I believe that it would be sufficient to simply delete the old 
text - the old text isn't correct, and the new text is sufficiently 
vague that reminds me of a legal disclaimer.  I don't think it offers 
any meaningful guidance to an implementor.   I would participate in a 
consensus on this point either with the new text, or with the old text 
removed.

LL17: I agree with the proposed change.

LL19: I agree to this if and only if LL23 is rejected.   I think these 
two issued need to be tied together.   The protocol is less susceptible 
to denial of service if LL19 is accepted and LL23 is rejected.   
However, I am not sure there is consensus to reject LL23.   Without 
rejecting LL23, LL19 completely breaks link-local, and so obviously it 
can't be accepted.   Having said that, I would prefer that LL19 be 
accepted and LL23 rejected, rather than that LL23 be accepted and LL19 
rejected.   If LL19 is accepted and LL23 rejected, some other proposed 
changes will need to be reconsidered.

---

From: "Philip Nye" <[email-masked]>
Date: Sun, 16 Feb 2003 21:11:17 -0000

> From: "Ted Lemon" <[email-masked]>
...
> > regardless of the TTL in the IP header.

While I agree that in general "the implementor has no way of knowing whether
or not a particular node is a router". I do not think the requirement on the
sender should be removed as there is no guarantee that routers on the local
link will be LL compliant and there is also no guarantee that the stack will
_not_ know where a router is.

A packet for routing is distinguished by the fact that it's destination
address is different from that of the host it is sent to, so the requirement
for IPv4LL is really that packets are only ever sent directly to their
destination address.

How about this:

> Any IPv4 packet sent whose source and/or destination address is in the
> 169.254/16 prefix MUST be sent directly to its final destination, as
> identified by ARP, on the same link. It MUST not be sent to any other
> destination as it might then be forwarded off the link.

Then add the ban on forwarding as well.

Philip

---

From: Mika Liljeberg <[email-masked]>
Date: 17 Feb 2003 01:32:21 +0200

> How about this:

Let's try something a bit more precise:

A compliant node MUST use the 169.254/16 prefix, in addition to any
other on-link prefixes it may have, when determining whether a
particular destination is on-link. A compliant node MUST NOT send a
packet having a source address in the 169.254/16 range to an off-link
destination. A received packet with a source address in the 169.254/16
range and a destination address that is not one of the receiving node's
own IP addresses MUST be discarded.

	MikaL

---

From: Ted Lemon <[email-masked]>
Date: Sun, 16 Feb 2003 17:35:18 -0600

>> identified by ARP, on the same link.

The text already says this, although with somewhat different wording.

>> It MUST not be sent to any other

There's no reason to say this.   The existing text already excludes 
this.   Then only time that the packet could get forwarded off-net 
would be if the IPv4ll implementation were broken, in that it did not 
follow the explicit recommendation of the standard, or if there were a 
router doing proxy arp, in which case the IPv4ll implementation would 
have no way of knowing that it was a router.

As I said, I am not going to object strongly to the text as written, 
but I do think that putting in this requirement, whether worded the way 
you have done, or worded as the document currently is, has the 
potential to create confusion, and that is why I raised the issue.

---

From: Mika Liljeberg <[email-masked]>
Date: 17 Feb 2003 01:48:49 +0200

> potential to create confusion, and that is why I raised the issue.

One thing I don't much like in any of the proposed wordings is the role
of ARP. Normally, on-link determination is done as part of route
selection *prior* to running ARP. First you determine whether the packet
needs to be sent to a gateway or to an on-link destination. Then if you
don't have the link-layer address you run ARP to get it. Using ARP for
on-link determination is a perversion that totally scrambles the logic
of existing stacks. That's why I proposed a different wording in the
previous mail.

	MikaL