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

From: Richard Draves <[email-masked]>
Date: Fri, 29 Oct 1999 00:00:05 -0700

> The effect of your draft is to mandate the strong host model 
> (for sending at least).

No, the effect is to mandate the strong host model for sending unless an
application or upper-layer specifies a source address.

>   | 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.

I don't know about the rest of you, but I want IPv6 to be a better protocol
than IPv4.

> 
>   | - 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.

No, my draft is concerned with source address selection for all kinds of
destination addresses, including multicast destinations.

> 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).

I don't see the problem - the machine enables its routing functionality, so
it stops listening to router advertisements and can forward between its
interfaces. Then it downloads its configuration. In practice you'd want some
boot-time config at least so the machine knows not to listen to router
advertisements and pick up stray undesirable state before configuring
itself.
 
> 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.

Yes, the routing protocol as an upper-layer or application could always
specify a source address.

>   | 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.

Why is that? I would expect the source address of the new connection to be
the address assigned to the outgoing interface. 

> 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.

Well I'm no expert on IETF requirements for standards. But if your argument
is carried to its conclusion then you're saying that there can be no
standard at all for source address selection because apps could always
override anything the standard said. Surely that's not right.

I also want to agree with Francis, if the candidate set is opened up to
include addresses from interfaces other than the outgoing interface, then
it's not at all clear what the right circumstances are. You suggest scope.
But there's also deprecated addresses (the outgoing interface only has
deprecated addresses, another interface has a preferred address) and policy
preferences (sending to a 6to4 address, the outgoing interface only has a
native address but another interface has a 6to4 address),
longest-matching-prefix, etc. (I have a proposal on this at the very end.)

Another issue, back in your original example:

> Eg: consider a node with two interfaces A and B.   Allow A to have
> a global address GA (and a local address LA though that won't be
> relevant here).   Allow B to have just a local address LB (no global
> prefix has been advertised on that link).   For the purposes of
> this example it doesn't matter whether the local addresses are site
> local, link local (or both).
> 
> Then consider a packet to be sent to the destination global address GD
> (exactly one address is available, and it has global scope).
> 
> And then assume that the node has chosen to transmit the 
> packet through
> interface B (as assumed in section 5 of the draft, the 
> outgoing interface
> has been chosen already).

OK, now your example assumes that it will be best (= maximize chances of
successful communication) if the node uses source address GA.
It's not at all clear that's the case.

For example the interfaces A & B may be connected to networks that don't
have any connectivity. (I use nodes configured like this every day.) So
although GD can be reached through interface B, GD can't send replies back
to GA. However GD may actually be on-link to interface B, so that using
source address LB would lead to successful communication.

Note that in this example the node is a host, not a router. (Otherwise the
node itself would be the connectivity between the two networks.)

I also have some thoughts on "unnumbered interfaces". I still can't see that
they are actually useful for v6. (But keep trying, you might convince me yet
:-) IPv6 has plenty of address space. It's the big feature. Tunnels can be
given /126s. About manageability: Simplicity leads to manageability, and
it's simpler to just give interfaces their own addresses instead of trying
to make unnumbered interfaces work.

However it seems people have come to love unnumbered interfaces and don't
want to give them up. So they should be supported. It also seems that
unnumbered interfaces are desired for routers, they're not an issue for
hosts.

So my conclusion so far for modifying the draft is:

a) for routers, open up the candidate set to include addresses assigned to
all interfaces. (Or more precisely, the outgoing interface plus interfaces
that can internally forward the destination address to the outgoing
interface. link-local destinations can't be forwarded between interfaces,
site-local destinations can only be forwarded between interfaces in the same
site.)

b) add a rule (between 5 & 6) preferring source addresses assigned to the
outgoing interface. So scope, deprecated/preferred, and policy issues are
all more important, and longest-matching-prefix is less important.

Thanks,
Rich
--------------------------------------------------------------------
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: Steve Deering <[email-masked]>
Date: Fri, 29 Oct 1999 07:27:42 -0700

Sorry for not having the cycles to engage in this address-selection
discussion at the moment, but here's a nit that caught my eye:

At 12:00 AM -0700 10/29/99, Richard Draves wrote:
>...link-local destinations can't be forwarded between interfaces,...

Link-locals *can* be forwarded between interfaces connected to the same link.

Steve

---

From: [email-masked] (Sam Manthorpe)
Date: Fri, 29 Oct 1999 10:44:11 -0700 (PDT)

> Link-locals *can* be forwarded between interfaces connected to the same link.

I'm probably missing something silly here, but isn't that a bad
thing to do?  Doesn't it lead to duplication of packets on the wire?
Or are you talking about source routing (in which case there may be
some reason to do that if the packet contains some interesting 
hop-by-hop option)?

-- Sam

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sam Manthorpe, SGI.  tel: (650)933-2856 fax: (650)932-2856  [email-masked]
--------------------------------------------------------------------
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: Steve Deering <[email-masked]>
Date: Fri, 29 Oct 1999 11:10:17 -0700

>thing to do?  Doesn't it lead to duplication of packets on the wire?

Yes, it is not a desirable steady state to be in.  (That's why I
mentioned in my previous message that a router finding itself doing
that ought to issue a Redirect to try to make it stop.)

>some reason to do that if the packet contains some interesting 

No, I wasn't thinking of source routing, but that is another (better)
example of how the situation might arise.

Steve