Re: WG ACTION: 2 weeks to discuss [LL56] Contradictory text?

"Philip Nye" <[email protected]> Fri, 7 May 2004 10:53:45 -0000
Newsgroups gmane.ietf.zeroconf
Organization Engineering Arts
Message-ID <013901c43421$91985060$131010ac@aldebaran>
I support Erik's analysis.

The special case of having a routable address but only a locally resolvable name and particularly if there is some knowledge that the name will not be used off-link is sufficient justification for an implementer to reject the "SHOULD" and is why this is not "MUST".

Finally, I don't think this is a deal breaker and it should be too late to make a change.

Philip

----- Original Message ----- 
From: "Erik Guttman" <[email protected]>
To: <[email protected]>
Sent: Tuesday, May 04, 2004 10:59 PM
Subject: WG ACTION: 2 weeks to discuss [LL56] Contradictory text?


> Please post discussion of this issue to the mailing list over the 
> next two weeks
> ending May 18, 2004.  In order to accept this issued, we will need a strong WG
> consensus given that this is very late in the process.
> 
> Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of
> current issues and their status.
> 
> [LL56]
> 
> Description of Issue: Contradictory text?
> Submitter Name:                 Stuart Cheshire
> Submitter Email Address:        [email protected]
> Date first submitted: 04 May 04
> Reference:
> Comment Type ['t'ech|'e'dit]: t
> Prio ['S' Must|1 should|2 may]: S
> Section: 1.4, 1.8
> Rationale/Explanation:
> Lengthy Description:
> 
> [Stuart]
> 
> >         IPv4 addresses ...
> >       ... which can only be resolved on the local link ...
> >       ... SHOULD only be sent when a Link-Local address
> >       is used as the source address.
> 
> Sent how? In the header? In the payload? Doesn't this contradict the text
> later in the document that says:
> 
> >    There will be cases when devices with a configured Link-Local address
> >    will need to communicate with a device with a routable address
> >    configured on the same physical link, and vice versa.  The rules in
> >    Section 2.6  allow this communication.
> 
> This says that link-local addresses *can* be used when the source address
> is *not* link-local.
> 
> [Erik]
> 
> The IPv4 address would be sent in the LLMNR (DNS) payload.  I though
> that was obvious due the the context in the paragraph.
> 
> The first paragraph refers to text in section 1.4.b which discuss
> limitations of the use of IPv4 LL when used with LLMNR.  The second
> paragraph is in section 1.8 which discusses general communication
> between two hosts.  In the latter case, the text is definitely
> appropriate.
> 
> I believe there is no contradiction.  1.4.b does not hinder the use of
> LLMNR or IPv4 LL configuration except in one case:  A host implementor
> is admonished (using SHOULD) to only hand out a LL address using LLMNR
> when the host has a LL configuration and only from an interface which in
> fact has been configured with an LL adddress.
> 
> [Stuart]
> 
> I disagee.
> 
> As stated, a device with a routable address, and a link-local-scope name
> of some kind, is prohibited from answering queries for that name, because
> the name can only be resolved on the local link, but the device doesn't
> have a Link-Local address to use as the source IP address.
> 
> [Erik]
> 
>   The full quote is:
> 
>        IPv4 addresses and names which can only be resolved on the local
>        link SHOULD NOT be forwarded, they SHOULD only be sent when a
>        Link-Local address is used as the source address.  This strong
>        advice should hinder limited scope addresses and names from
>        leaving the context in which they apply.
> 
>      There is no prohibition.  There is only a 'SHOULD' implying that
>      this is not a great idea.  The issue of 'leaving the context ni
>      which they apply' is not very serious *today* since LLMNR has only
>      LL scope.  In the future, LLMNR might be admin scope MNR.  In this
>      case, we will need the SHOULD above - so that link-local scope
>      identifiers (addresses and names) are properly contained.
> 
> Requested Change:
> 
> TEXT NEEDED
>