Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer

From: Ralph Droms <[email-masked]>
Date: Tue, 16 Dec 2003 12:00:40 -0500

In response to this issue, I suggest deleting subsections 1.7 and 2.11, and 
inserting the following text as the last subsection of section 1 (in 
particular, to come after subsection 1.9. "Communication with Routable 
Addresses"):

1.x When to configure a Link-Local IPv4 address on an interface

    Having addresses of multiple different scopes assigned to an
    interface, with no adequate way to determine in what circumstances
    each address should be used, leads to complexity for applications
    and confusion for users.  A host with an address on a link can
    communicate with all other devices on that link, whether those
    devices use Link-Local addresses, or routable addresses.  For these
    reasons, a host SHOULD NOT have both a valid routable address and a
    Link-Local IPv4 address configure on the same interface.

    A routable address is any address that is:

    * a unicast address
    * not a loopback address
    * not in the 169..2.54/32 subnet reserved for Link-Local IPv4
      addresses

    A "valid routable address" is a routable address that passes the
    reachability test described in section 2 of "Detection of Network
    Attachment (DNA) in IPv4" [DNAv4].

    The assignment and use of a Link-Local IPv4 address on an interface
    is based solely on the state of the interface, and is independent
    of any other protocols such as DHCP or RADIUS.  A host MUST NOT
    alter its behavior and use of other protocols such as DHCP and
    RADIUS because the host has assigned a Link-Local IPv4 address to
    an interface.

    When an interface has a valid routable address configured on an
    interface, the host SHOULD NOT also assign a Link-Local IPv4
    address to that interface.

    If a host finds that an interface that was previous configured with
    a Link-Local IPv4 address is now configured with a valid routable
    address, the host MUST always use the routable address when
    initiating new communications, and MUST cease advertising the
    availability of the Link-Local IPv4 address through whatever
    mechanisms that address had been made known to others.  The host
    SHOULD continue to use the Link-Local IPv4 address for
    communications underway when the routable address was configured,
    and MAY continue to accept new communications addressed to the
    Link-Local IPv4 address.  Ways in which a valid routable address
    might be configured for the interface include:

    * Manual configuration
    * Address assignment through RADIUS or DHCP
    * Roaming of the host to a network on which a routable address
      assigned to the interface is valid

    If a host finds that an interface that was previously configured
    with a valid routable address no longer has a valid routable
    address, the host MAY identify a usable Link-Local IPv4 address (as
    described in section 2) and assign that address to the interface.
    Ways in which a valid routable address might no longer be assigned
    to an interface include:

    * Removal of the address from the interface through manual
      configuration
    * Expiration of the lease on the address assigned through DHCP
    * Roaming of the host to a new network on which the address is no
      longer valid.

    Further discussion of the issues in detection of transient failures
    and the use of DHCP in response to network attachment failure is
    provided in "Detection of Network Attachment (DNA) in IPv4".

---

From: Alex Karahalios <[email-masked]>
Date: Tue, 16 Dec 2003 13:19:29 -0700

Ralph,

Yes, I understand this, but I think the phrase you are proposing, a 
host "MUST cease advertising the availability of the Link-Local IPv4 
address through whatever mechanisms that address had been made known to 
others," will make it such that a new LL IPv4 device will not be able 
to interoperate on the network.

Take the case of a printer using mDNS, for example. A new device would 
only get routable address information from the printer, but the new 
device is only configured for LL IPv4 and thus is shut out of 
communicating with the printer.

Alex Karahalios

On Dec 16, 2003, at 11:09 AM, Ralph Droms wrote:

> Well, section 1.9 of draft-ietf-zeroconf-ipv4-linklocal-10.txt,
> "Communication with Routable Addresses", describes how two devices can
> communicate in the case you describe, where one device has a routable
> address and one device has a Link-Local IPv4 address.
>
> Of course, there's a difference between "finding" and "communicating 
> with".
> "Finding" printers is out of scope for Link-Local IPv4, so
> draft-ietf-zeroconf-ipv4-linklocal-10.txt doesn't address how the 
> computer
> determines the printer's address, regardless of whether the printer is 
> using
> a routable address or a Link-Local IPv4 address.
>
> - Ralph
>
> At 10:25 AM 12/16/2003 -0700, Alex Karahalios wrote:
>> Given the below text which specifies the a host "MUST cease 
>> advertising the availability of the Link-Local IPv4 address", could 
>> some explain how I would be able to make use of LL IPv4 addressing in 
>> the following circumstances:
>>
>> Let's say a printer stops advertising LL IPv4 addresses because it 
>> obtains a DHCP address. A new computer is introduced into the network 
>> that wants to print, but it cannot obtain a routable address, so it 
>> configures a LL IPv4 address. How is the new computer suppose to find 
>> the printer if the printer has stopped advertising its LL address?
>>
>> I've asked a similar version of this question before and was told 
>> that there are provisions in draft to address this, but the follow 
>> text preclude this.
>>
>> Thanks,
>>
>> Alex Karahalios
>>
>> On Dec 16, 2003, at 10:00 AM, Ralph Droms wrote:
>>

---

From: Alex Karahalios <[email-masked]>
Date: Tue, 16 Dec 2003 13:51:01 -0700

Ralph,

Sorry to imply you are proposing this text since it's part of section 
1.7 already...

Alex Karahalios

On Dec 16, 2003, at 1:19 PM, Alex Karahalios wrote:

> address through whatever mechanisms that address had been made known 
> to others," will make it such that a new LL IPv4 device will not be 
> able to interoperate on the network.
>
>> determines the printer's address, regardless of whether the printer 
>> is using
>>> some explain how I would be able to make use of LL IPv4 addressing 
>>> in the following circumstances:
>>>
>>> obtains a DHCP address. A new computer is introduced into the 
>>> network that wants to print, but it cannot obtain a routable 
>>> address, so it configures a LL IPv4 address. How is the new computer 
>>> suppose to find the printer if the printer has stopped advertising 
>>> its LL address?
>>>

---

From: "Philip Nye" <[email-masked]>
Date: Thu, 18 Dec 2003 09:40:09 -0000

Ralph's approach seems reasonable and I think improves the draft. However, I am concerned that as written it does not allow operation with stacks which only allow a single address per interface.

Philip

---

From: "Philip Nye" <[email-masked]>
Date: Thu, 18 Dec 2003 09:49:00 -0000

Alex,

Provided they are on the same link, the LL device _can_ communicate with the printer just so long as the printer has the necessary route for the 169.254.x.x network. This has been the preferred mode of operation for several successive drafts now. Communication between LL and routable hosts on the same link is perfectly possible.

I would expect a printer using mDNS to configure the necessary route automatically. Getting the IPv4LL draft to RFC status would make this even more likely!

Philip

---

From: Ralph Droms <[email-masked]>
Date: Thu, 18 Dec 2003 11:56:59 -0500

Philip - I think I surrounded the text that describes using multiple
addresses on an interface with conditionals (SHOULD, MAY) so that a stack
that only allows a single address on an interface can still be compliant
with the spec.  If you don't agree, can you point out the text that requires
multiple addresses on an interface and/or suggest new text?

- Ralph

At 09:40 AM 12/18/2003 +0000, Philip Nye wrote:
>Ralph's approach seems reasonable and I think improves the draft. However, 
>I am concerned that as written it does not allow operation with stacks 
>which only allow a single address per interface.
>
>Philip
>

---

From: Alex Karahalios <[email-masked]>
Date: Thu, 18 Dec 2003 14:06:35 -0700

Hi Philip,

Yes, this works. But what I am trying to address is that, due to the 
wording of section 1.7, the mDNS printer will no longer broadcast the 
LL address once it obtains a routable address and thus the LL only 
device will never know that the printer exists and thus cannot 
communicate with it.

That is why the phrase

    "the host MUST always use the routable address when
    initiating new communications, and MUST cease advertising the
    availability of the Link-Local IPv4 address through whatever
    mechanisms that address had been made known to others"

is not acceptable since it precludes LL only devices from participating 
in the network.

Alex Karahalios

On Dec 18, 2003, at 2:49 AM, Philip Nye wrote:

> Provided they are on the same link, the LL device _can_ communicate 
> with the printer just so long as the printer has the necessary route 
> for the 169.254.x.x network. This has been the preferred mode of 
> operation for several successive drafts now. Communication between LL 
> and routable hosts on the same link is perfectly possible.
>
> I would expect a printer using mDNS to configure the necessary route 
> automatically. Getting the IPv4LL draft to RFC status would make this 
> even more likely!
>

---

From: Erik Guttman <[email-masked]>
Date: Fri, 19 Dec 2003 14:40:23 +0100

Alex,

You are incorrect in asserting there is a problem.

A host whose interface is configured with a link-local address can
communicate with a host with a routable address (See Section 2.6.2).
The host with the link-local address may also *discover* the address
of a host with a routable address (on the same link), for example by
using mDNS.

A host with a routable address which complies with this specification
can communicate with a host configured with a link-local address
(See Section 3.3).  The host with the routable address that receives
discovery messages (such as sent by mDNS) will respond.  If the 
discoverer's source address is link-local, the discovered service will
respond to that destination address.

Best regards,

Erik

  = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

Alex Karahalios wrote:
> wording of section 1.7, the mDNS printer will no longer broadcast the LL 
> address once it obtains a routable address and thus the LL only device 
> will never know that the printer exists and thus cannot communicate with 
> it.
> 
> That is why the phrase
> 

-- 
  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
    Erik Guttman   -   N1 Manageability   -   Sun Microsystems
       cell: +49 172 865 5497   -   time zone: CET (GMT+1)

---

From: Alex Karahalios <[email-masked]>
Date: Fri, 19 Dec 2003 09:35:07 -0700

Eric,

OK, I see now. Based on section 3.3, a LL only device can sent directly 
to a routable address device (provided it's on the same link). And by 
section 2.6.2 the LL only device will ARP for the routable address.

Sorry for being dense about this. I was just focusing on section 1.7.

Thanks,

Alex

---

From: Robert Elz <[email-masked]>
Date: Fri, 19 Dec 2003 15:49:18 +0700

Date:        Thu, 18 Dec 2003 14:06:35 -0700
    From:        Alex Karahalios <[email-masked]>
    Message-ID:  <[email-masked]>

  | Yes, this works. But what I am trying to address is that, due to the 
  | wording of section 1.7, the mDNS printer will no longer broadcast the 
  | LL address once it obtains a routable address

yes, that's intended.

  | and thus the LL only device will never know that the printer exists

But how does that possibly follow?   The printer will just broadcast
its routable address instead, the LL only device will see that address,
and use it.   "LL-only" devices assume that *every* IP address is on the
local link (as to them, that's true, for the world as they know it).

kre

---

From: Alex Karahalios <[email-masked]>
Date: Fri, 19 Dec 2003 10:30:55 -0700

Yes, you are right - I understand now. I was just focusing on section 
1.7 of the draft and ignoring the rest of the draft.

Thanks,

Alex