Subject: Re: draft-ipngwg-default-addr-select-00.txt

From: Robert Elz <[email-masked]>
Date: Wed, 27 Oct 1999 19:50:31 +1000

Date:        Tue, 26 Oct 1999 17:53:47 -0700
    From:        Richard Draves <[email-masked]>
    Message-ID:  <4D0A23B3F74DD111ACCD00805F31D81014515D27@RED-MSG-50>

  | The root issue seems to be the proposed "semi-strong" host model.

Perhaps, but ...

  | I just checked Steve Deering's Tokyo presentation - he defined it as "source
  | address SHOULD belong to the originating interface". (The presentation
  | didn't define the receive side behavior.)

I wasn't in Tokyo, but I have heard Steve describe this before, and it
never seemed horribly unreasonable ... but the "SHOULD" is the key there.

That means that if there are good reasons for doing differently, one can
do differently.   Your draft says MUST which doesn't allow that variation.
The effect of your draft is to mandate the strong host model (for sending
at least).

  | In discussion of the SHOULD in the semi-strong definition, the consensus was
  | that source address selection should explicitly call out any exceptions.

That's reasonable - as long as it does not pretend that it is now possible
to anticipate all possible future exceptions.   That's more or less what the
text I sent for section 4.1 was doing, I think.

  | I think there are good reasons to prefer a strong or semi-strong host model
  | for IPv6. Among them:
  | - Redirect won't work if a source address from the "wrong" interface is used

Yes, that's a nuisance.   Not fatal, just a nuisance though.   It turns out
not to matter on the interfaces which will tend not to have global addresses
(the ones I am concerned with at the minute) as they're essentially all point
to point, and redirect makes no sense anyway.   The same problem applies to
the case where the application has specified the source address (or it is
forced because of the address chosen by the peer) and it isn't the one
which applies to the outgoing interface (which may also have been specified
by the application).   It has been with us with IPv4 as well.   I doubt that
this is enough of an argument to influence anything.

  | - Similarly, I'm told multicast routing might not work

Your draft is explicitly concerned with unicast address selection,
so I'm not sure this is relevant.   It may be that an address without
a scope N unicast address can't participate in scope N multicast, I think
I could cope with that.

  | - Predictable host behavior is a good thing

Yes, but workable host behaviour is even better.

  | I think it's more than just sophistry - the semi-strong model and hence
  | source address selection will need a good definition of "interface".

Yes, it would.

  | The
  | current definitions (an interface is an attachment to a link and a link is
  | medium for transmitting packets below the IP layer) might be too imprecise
  | for our purposes here.

Maybe.   I view a link as a device (physical or logical) via which IPvN
datagrams (of a particular version) can be transmitted from one node
to another, without any intermediate IPvN routing of that particular
packet.   An interface is the point at which a packet is placed on a
link, or removed from it.    The technology used to move the packet
(be it a tunnel over another instance of the same version of IP or
over some other technology, or something physical).

  | I'm not sure I understand the scenario. Is the firewall machine routing
  | between its internal and external interfaces?

Not for these purposes.

  | If it is not, then I would
  | configure it with a global address on its external interface and then I
  | could use site-local addresses if I wanted on the internal interfaces &
  | networks.

You could, and that might be a reasonable choice.   The question is not
whether you can do that, but whether you must.

  | Since it would be acting as a host on the external network, it
  | would need a global address there.

This is the issue - as long as it has A global address, is it
necessarily true that it MUST have an address on every interface?
One global address (plus the necessary routing infrastructure) is
all that a host should need to work, more than that might be beneficial,
but need it be mandatory?

  | Is it useful to have hosts with "unnumbered" interfaces?

If it is useful to have routers with unnumbered interfaces, then
hosts with unnumbered interfaces are a fact of life - because before
it enables routing, any router is a host, but the interfaces
are still all there (or most of them are, tunnels might not be perhaps).

If/when we develop protocols to allow a local router to fetch some of
its config from the service provider, then the router might want to
send packets out its (unnumbered) point to point link to the ISP, before
it starts acting as a router.   Unless the target of thost packets is
the device at the other end of the point to point link, then a global
address will be needed to talk to it (link local cannot work, as the
link here has just the two nodes, and almost by definition site local
can't work, as the link is the border between the sites).

Now you can always "avoid" the rule in that kind of case by simply proclaiming
that the application is specifying the source address, rather than allowing
the kernel to choose it (when it is all inside one piece of software
how you distinguish I can't really tell).   I don't think this helps.

  | No no, the scenario is an incoming TCP connection. TCP needs to reverse the
  | source & destination addresses, but it came in on a unidirectional interface
  | so the reply has to go out a different interface.

Yes, I understand that scenario.   You missed my point.   If I have a host
with unidirectional links (a pair I assume), then I am just as likely to
want to initiate a connection (with only the destination address currently
specified) for communications which will use the outgoing side of the
unidirectional link pair.  For that, I would expect that the source address
ought to be the address of the incoming interface, not the outgoing one.

Aside from all of this, I suspect that this requirement fails the
testability test anyway - that is, there's no way you can really tell
if the implementation would be complying with your MUST (assuming it
remains) or not from outside.   There's no plan to prohibit an
application from specifying its source address (to be anything which belongs
to the node) I hope ... from outside you simply can't tell whether or
not an application has done that, or whether the kernel just assigned the
address for the application to use.

kre

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Richard Draves <[email-masked]>
Date: Tue, 26 Oct 1999 17:53:47 -0700

The root issue seems to be the proposed "semi-strong" host model.

I just checked Steve Deering's Tokyo presentation - he defined it as "source
address SHOULD belong to the originating interface". (The presentation
didn't define the receive side behavior.)

Note that this breaks down into two different cases:
a) if the source address is specified, how this constrains the originating
interface
b) if the originating interface is specified, how this constrains the source
address

Only case b) is of concern for my draft.

In discussion of the SHOULD in the semi-strong definition, the consensus was
that source address selection should explicitly call out any exceptions. But
the only exception that anyone came up with was replying to requests
arriving on unidirectional interfaces, which is an issue for case a) not
case b). Hence I made it a MUST in my draft, hoping to provoke this
discussion.

Mixing responses to Tim & kre (sorry this is long):

From kre:
> That would be overspecification.   There's no particular 
> reason why any
> of these models must be part of the specs - implementations can be of
> strong, weak, or the "semi-strong" kind as needed.

I think there are good reasons to prefer a strong or semi-strong host model
for IPv6. Among them:
- Redirect won't work if a source address from the "wrong" interface is used
- Similarly, I'm told multicast routing might not work
- Predictable host behavior is a good thing

From Tim:
> > Ignoring the "fix your implementation" response...
> 
> Hmm...  This is a bit pejorative.  The implementation does not require
> fixing.  It works as intended.

Sorry, no offense intended.

> I freely admit that in order to support routing protocols 
> over tunnels,
> implement 6to4 or 6over4 the implementation of tunnel interfaces needs
> to be more expansive.
> 
> However, to support automatic tunneling and support configured tunnels
> modeled as routing table entries the implementation is adequate to the
> task.

Sounds somewhat similar to how MSR IPv6 works right now. In our case,
configured tunnels are not interfaces; you can't assign an address to a
configured tunnel endpoint. We implement 6over4 separately as "real"
interfaces.

From kre:
>   | One thought is that an interface that can't be assigned addresses
>   | shouldn't qualify as an interface.
> 
> This sounds like playing with words to suit the definition.   

I think it's more than just sophistry - the semi-strong model and hence
source address selection will need a good definition of "interface". The
current definitions (an interface is an attachment to a link and a link is
medium for transmitting packets below the IP layer) might be too imprecise
for our purposes here. For example, sometimes it might be useful to view
IPsec tunnel-mode associations as point-to-point links, and sometimes not.

From kre:
>   | A final thought, appropriate only for routers: you could 
> consider the
>   | ethernet interface to be originating/receiving packets using the
>   | global address, and it's internally forwarding the 
> packets over to the
>   | tunnel interface. If this is a desired viewpoint, I'd 
> want to change
>   | the draft to be more explicit about effectively enlarging the
>   | candidate set of source addresses on routers. 
> 
> It can be viewed that way, but this is really more artificial 
> layering,
> which isn't going to match what anyone is really doing - and 
> there's also
> no real reason why this functionality needs to be confined to routers.

I disagree - it's a very natural conceptualization to think of a router as
forwarding internally among its interfaces.

There are real reasons for confining this functionality to routers - see the
comments about Redirect and multicast routing above, both of which apply to
hosts but not routers.

From kre:
> And for initiating communication - all I need for that is to have my
> point to point link terminate on my firewall, which is running my
> mailer - when I send mail, to the world, it goes internally to the
> firewall, which relays it out its point to point link into the world.
> The firewall box has a global address for the LAN interface(s) on the
> internal side, it doesn't really need one for its *DSL, or ISDN, or
> whatever, interface to the world, just a link local will do 
> fine there.

I'm not sure I understand the scenario. Is the firewall machine routing
between its internal and external interfaces? If it is not, then I would
configure it with a global address on its external interface and then I
could use site-local addresses if I wanted on the internal interfaces &
networks. Since it would be acting as a host on the external network, it
would need a global address there.

If it is acting as a router with filtering, then I think it would still be
sensible to assign a global address to the external interface. But as a
router it could logically originate a packet on an internal interface with a
global address and then send the packet out the external interface, so the
external interface could do without a global address if that were desired.

From Tim:
> Yes, that is in essence what is happening.  I think the 
> language would need to
> be tightened (loosened?) to take into account the IPv6 
> equivalent of unnumbered
> interfaces.  That assumes of course that we determine that a 
> facility like
> unnumbered interfaces still has utility in the IPv6 world.
> 
> The reason these things have been used in the IPv4 world was 
> to avoid burning
> down lots of address space at the server end of PPP dialup 
> connections.  That
> is less of a concern for IPv6 however they also have the 
> added benefit of
> making PPP dialup boxes at least a little easier to administer.

Is it useful to have hosts with "unnumbered" interfaces?

From kre:
>   | One compelling scenario raised at the Tokyo meeting was 
> with unidirectional
>   | interfaces, where one would necessarily need to reply by 
> sending packets out
>   | another interface. But in that situation the source 
> address is specified by
>   | an upper-layer or application.
> 
> Huh?    Why?
> 
> Why would the application be any more likely to supply the address in
> that case than in any other?   Are applications supposed to be endowed
> with knowledge of unidirectional links for some reason?

No no, the scenario is an incoming TCP connection. TCP needs to reverse the
source & destination addresses, but it came in on a unidirectional interface
so the reply has to go out a different interface.

Thanks,
Rich

---

From: Jim Bound <[email-masked]>
Date: Wed, 27 Oct 1999 13:12:43 -0400

Richard,

Good job.  I don't see any technical issues with the draft.
I think we should all implement it as soon as possible and get UNH to
test it on site with the IPv6 machines located at UNH.  Then lets do
interoperability bake off at Sun Connectathon which I believe is March
2000?

Can't really tell if it all will work with the rest of the
implementation until we implement it.

I will also throw this over the wall to the IPv6 Forum Deployment
Technical Directorate to view it from a deployment technical perspective 
and get the BINDv9 vendors and ISC folks to get some input to this process and
most likely bind workers too as the place where it will be implemented
for getipxxx will be in our DNS resolvers.

I know you can't be at D.C. and I would suggest to the chairs this not
be discussed in depth other than update or maybe depicting the
algorithms without you there.  Unless you want to select a DRI.  

thanks and good job,
/jim

---

From: Francis Dupont <[email-masked]>
Date: Wed, 27 Oct 1999 23:22:36 +0200

In your previous mail you wrote:

=> semi is semi-strong means a SHOULD in place of a MUST...

   In our (MSR IPv6) case, configured tunnels are not interfaces; you
   can't assign an address to a configured tunnel endpoint.

=> how can we use RIPng over such tunnels? This position has not been
defensible since San Jose IETF meeting...

=> yes of course it is useful because a host can have point-to-point
interfaces which are natural candidates for being "unnumbered"
(because there is nothing to address :-).

Regards

[email-masked]

PS: here is a variation on the unidirectional link.
At home you have a host with a costly and slow dialup connection
and a fast, cheap but unidirectional satellite interface (with only
reception, in France 20% of homes with a television have a satellite
with interactive capabilities: this is a *real* case).
You'd like to use the dialup only as the return path then you'd like
to get the satellite interface global address as source even when
the outgoing interface is always the dialup one. In fact you'd like
to use a dialup interface address only for communications in the dialup
link zone (*), ie. when the destination is the local node or the other end
of the dialup line. Of course you'd like to get the right setup
automagically, ie. source selection won't be the job of applications!

PPS: the zone concept was introduced by Steve in Japan, this is nice
and to get a document about this will be even nicer (:-)...
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------