[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: Re: Strange use of link-local (was: [Technical Errata Reported] RFC6874 (3630))
From: Tim Chown <tjc () ecs ! soton ! ac ! uk>
Date: 2013-05-29 6:18:50
Message-ID: EMEW3|0bdacdb5983756ea5d3dee7295117e37p4S7K703tjc|ecs.soton.ac.uk|D9870A41-91CC-4383-89DB-B64928DD9DD8 () ecs ! soton ! ac ! uk
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On 29 May 2013, at 00:57, Michael Sweet <msweet@apple.com> wrote:
> Brian,
>
> On 2013-05-28, at 4:38 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> > I'm increasingly baffled by the use case. If the host is
> > in a context where it can reach a server *and* has more than
> > one interface (such that a ZoneID is needed at all), it
> > shouldn't be using a link local address anyway - it
> > should have configured a global scope address (possibly
> > under a ULA prefix). Discussion of this use case surely
> > belongs in MIF or HOMENET.
>
> Most hosts (and probably all of the ones we care about) have multiple network \
> interfaces, if only the loopback interface plus some sort of external network \
> interface, forcing the use of the zoneid. Also, the most common place you would \
> need to use a link-local address for access is the place where global scope \
> addresses are basically never used - the home.
> So I agree that the MIF or HOMENET working groups might have something to say here, \
> but RFC 6874 was published by *this* group and IPv6 link local addresses have \
> broader context than either of the other groups.
Indeed, the single subnet view may be the case today for IPv4 homenets, but not \
necessarily so in an IPv6 homenet future. See \
http://tools.ietf.org/html/draft-ietf-homenet-arch-08. So any design should take \
that into account.
One interesting question for homenet is how zeroconf naming and service discovery \
protocols are extended to work in routed homenets. Protocols such as PCP will also \
need to work in such environments should devices wish to open firewall holes. If \
there are other cases where link-local protocols need to work across multi-subnet \
zeroconf environments, where those environments are typically single subnets today, \
those would be good to tease out.
Tim
>
> >
> > Brian
> >
> > On 29/05/2013 07:34, Ray Hunter wrote:
> > > Warning: post contains dumb questions.
> > >
> > > Michael Sweet wrote:
> > > > Christian,
> > > >
> > > > On 2013-05-24, at 1:45 PM, Christian Huitema <huitema@microsoft.com> wrote:
> > > > > Can we move from the process discussion to the technical discussion?
> > > > >
> > > > > Michael raised an interesting issue, and we have to analyze it. The \
> > > > > consensus of the working group so far is that interface identifiers are \
> > > > > private to the host, that any leakage outside the host should be prevented, \
> > > > > and that a way to prevent that leakage is to ask proxies to erase them \
> > > > > whenever they have an opportunity. Michael points that some servers take an \
> > > > > opposite approach, want to record the interface from which the host called \
> > > > > them, and want to ensure that further calls in the same session use exactly \
> > > > > the same interface. That seems that a fairly legitimate debate, and I can \
> > > > > see two alternatives -- one would be to reaffirm the old guidance and \
> > > > > provides alternative to ensure session continuity, and the other would be \
> > > > > to reverse the guidance and accept that the layer violation performed by \
> > > > > servers is just fine.
> > > >
> > > > (the following is printer-centric, but the same applies to network video \
> > > > cameras and other embedded network devices)
> > > > Some background: HTTP and IPP services in printers include absolute URIs in \
> > > > the content they return. For IPP this can be http/https URLs to the printer's \
> > > > web page, ICC profiles, and other resources, along with the ipp/ipps URIs \
> > > > that the printer supports. For HTTP the most common are https URLs for \
> > > > "secure" areas of the printer's web interface. Because a printer is often \
> > > > known by multiple names and addresses ("printer.local.", \
> > > > "printer.example.com.", 192.168.0.100, fe80::1234, etc.), the implementation \
> > > > guidance (and in IPP Everywhere, this is a conformance requirement) is that \
> > > > the server use the HTTP Host header provided in the request in the \
> > > > host/address field of its responses, subject to the usual security \
> > > > considerations (SHOULD validate Host value, etc.) This allows the client to \
> > > > use the name or address it can resolve/connect to and makes sure that the \
> > > > printer-generated absolute URIs lead back to same printer.
> > > > All of this falls apart with link-local addresses and RFC 6874. Because the \
> > > > client is required to remove the zoneid from the outgoing request, the URIs \
> > > > it gets back from the server are no longer "reachable".
> > > Trying to understand what's going on here and what the root problem is.
> > >
> > > I have some dumb questions:
> > >
> > > Is the zoneid in the URI the interface on the client or the server node?
> > >
> > > What does other party learn from this information, since zoneid is
> > > currently defined as being local to the node and has no significance
> > > outside the context of the node?
> > >
> > > If the other party learns nothing, and the originating node just needs
> > > to hear an echo of it's own information for it's own use, what's wrong
> > > with using a cookie (server originated), or a hidden variable (client
> > > originated), to transport this interface information along with the
> > > request/reply?
> > >
> > > What if both the server AND the client have multiple interfaces: how do
> > > they both know which local interface on their own node is mutually
> > > connected and to be used for communication? There's only one single
> > > zoneid in the URI, so presumably one of the nodes is lacking some
> > > information.
> > >
> > > Shouldn't both nodes be using ND to learn this information?
> > > If there's nothing in the cache, try all interfaces?
> > >
> > > regards,
> > > RayH
> > >
> > > > What I propose is that we change the wording to allow the zoneid in the Host \
> > > > header but not in the Request-URI. HTTP proxies would be required to strip \
> > > > any zoneid information in the Host header. HTTP servers would be required to \
> > > > ignore any zoneid information for purposes of address validation but include \
> > > > it for any absolute URIs to the server they generate.
> > > > Thoughts?
> > > >
> > > > _________________________________________________________
> > > > Michael Sweet, Senior Printing System Engineer, PWG Chair
> > > >
> > > >
> > >
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf.org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------
> > >
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
[Attachment #5 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html \
charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: \
space; -webkit-line-break: after-white-space; "><br><div><div>On 29 May 2013, at \
00:57, Michael Sweet <<a href="mailto:msweet@apple.com">msweet@apple.com</a>> \
wrote:</div><br class="Apple-interchange-newline"><blockquote \
type="cite">Brian,<br><br>On 2013-05-28, at 4:38 PM, Brian E Carpenter <<a \
href="mailto:brian.e.carpenter@gmail.com">brian.e.carpenter@gmail.com</a>> \
wrote:<br><blockquote type="cite">I'm increasingly baffled by the use case. If the \
host is<br>in a context where it can reach a server *and* has more than<br>one \
interface (such that a ZoneID is needed at all), it<br>shouldn't be using a link \
local address anyway - it<br>should have configured a global scope address \
(possibly<br>under a ULA prefix). Discussion of this use case surely<br>belongs in \
MIF or HOMENET.<br></blockquote><br>Most hosts (and probably all of the ones we care \
about) have multiple network interfaces, if only the loopback interface plus some \
sort of external network interface, forcing the use of the zoneid. Also, the \
most common place you would need to use a link-local address for access is the place \
where global scope addresses are basically never used - the home.<br><br>So I agree \
that the MIF or HOMENET working groups might have something to say here, but RFC 6874 \
was published by *this* group and IPv6 link local addresses have broader context than \
either of the other groups.<br></blockquote><div><br></div>Indeed, the single subnet \
view may be the case today for IPv4 homenets, but not necessarily so in an IPv6 \
homenet future. See <a \
href="http://tools.ietf.org/html/draft-ietf-homenet-arch-08">http://tools.ietf.org/html/draft-ietf-homenet-arch-08</a>. \
So any design should take that into account. </div><div><br></div><div>One \
interesting question for homenet is how zeroconf naming and service discovery \
protocols are extended to work in routed homenets. Protocols such as PCP will \
also need to work in such environments should devices wish to open firewall holes. If \
there are other cases where link-local protocols need to work across multi-subnet \
zeroconf environments, where those environments are typically single subnets today, \
those would be good to tease out. \
</div><div><br></div><div>Tim</div><div><br><blockquote \
type="cite"><br><blockquote type="cite"><br> Brian<br><br>On 29/05/2013 \
07:34, Ray Hunter wrote:<br><blockquote type="cite">Warning: post contains dumb \
questions.<br><br>Michael Sweet wrote:<br><blockquote \
type="cite">Christian,<br><br>On 2013-05-24, at 1:45 PM, Christian Huitema <<a \
href="mailto:huitema@microsoft.com">huitema@microsoft.com</a>> \
wrote:<br><blockquote type="cite">Can we move from the process discussion to the \
technical discussion?<br><br>Michael raised an interesting issue, and we have to \
analyze it. The consensus of the working group so far is that interface identifiers \
are private to the host, that any leakage outside the host should be prevented, and \
that a way to prevent that leakage is to ask proxies to erase them whenever they have \
an opportunity. Michael points that some servers take an opposite approach, want to \
record the interface from which the host called them, and want to ensure that further \
calls in the same session use exactly the same interface. That seems that a fairly \
legitimate debate, and I can see two alternatives -- one would be to reaffirm the old \
guidance and provides alternative to ensure session continuity, and the other would \
be to reverse the guidance and accept that the layer violation performed by servers \
is just fine.<br></blockquote><br>(the following is printer-centric, but the same \
applies to network video cameras and other embedded network devices)<br><br>Some \
background: HTTP and IPP services in printers include absolute URIs in the content \
they return. For IPP this can be http/https URLs to the printer's web page, ICC \
profiles, and other resources, along with the ipp/ipps URIs that the printer \
supports. For HTTP the most common are https URLs for "secure" areas of the printer's \
web interface. Because a printer is often known by multiple names and addresses \
("printer.local.", "<a href="http://printer.example.com">printer.example.com</a>.", \
192.168.0.100, fe80::1234, etc.), the implementation guidance (and in IPP Everywhere, \
this is a conformance requirement) is that the server use the HTTP Host header \
provided in the request in the host/address field of its responses, subject to the \
usual security considerations (SHOULD validate Host value, etc.) This allows \
the client to use the name or address it can resolve/connect to and makes sure that \
the printer-generated absolute URIs lead back to same printer.<br><br>All of this \
falls apart with link-local addresses and RFC 6874. Because the client is \
required to remove the zoneid from the outgoing request, the URIs it gets back from \
the server are no longer "reachable".<br></blockquote>Trying to understand what's \
going on here and what the root problem is.<br><br>I have some dumb \
questions:<br><br>Is the zoneid in the URI the interface on the client or the server \
node?<br><br>What does other party learn from this information, since zoneid \
is<br>currently defined as being local to the node and has no significance<br>outside \
the context of the node?<br><br>If the other party learns nothing, and the \
originating node just needs<br>to hear an echo of it's own information for it's own \
use, what's wrong<br>with using a cookie (server originated), or a hidden variable \
(client<br>originated), to transport this interface information along with \
the<br>request/reply?<br><br>What if both the server AND the client have multiple \
interfaces: how do<br>they both know which local interface on their own node is \
mutually<br>connected and to be used for communication? There's only one \
single<br>zoneid in the URI, so presumably one of the nodes is lacking \
some<br>information.<br><br>Shouldn't both nodes be using ND to learn this \
information?<br>If there's nothing in the cache, try all \
interfaces?<br><br>regards,<br>RayH<br><br><blockquote type="cite">What I propose is \
that we change the wording to allow the zoneid in the Host header but not in the \
Request-URI. HTTP proxies would be required to strip any zoneid information in \
the Host header. HTTP servers would be required to ignore any zoneid \
information for purposes of address validation but include it for any absolute URIs \
to the server they generate.<br><br>Thoughts?<br><br>_________________________________________________________<br>Michael \
Sweet, Senior Printing System Engineer, PWG \
Chair<br><br><br></blockquote><br>--------------------------------------------------------------------<br>IETF \
IPv6 working group mailing list<br><a \
href="mailto:ipv6@ietf.org">ipv6@ietf.org</a><br>Administrative Requests: \
https://www.ietf.org/mailman/listinfo/ipv6<br>---------------------------------------- \
----------------------------<br><br></blockquote></blockquote><br>_________________________________________________________<br>Michael \
Sweet, Senior Printing System Engineer, PWG \
Chair<br><br>--------------------------------------------------------------------<br>IETF \
IPv6 working group mailing list<br><a \
href="mailto:ipv6@ietf.org">ipv6@ietf.org</a><br>Administrative Requests: \
https://www.ietf.org/mailman/listinfo/ipv6<br>--------------------------------------------------------------------<br></blockquote></div><br></body></html>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic