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

From: Robert Elz <[email-masked]>
Date: Mon, 01 Nov 1999 19:06:45 +1100

Date:        Fri, 29 Oct 1999 00:00:05 -0700
    From:        Richard Draves <[email-masked]>
    Message-ID:  <4D0A23B3F74DD111ACCD00805F31D81014515D77@RED-MSG-50>

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

Which (aside from responding to incoming connections) means essentially
all the time, as applications just don't specify source addresses usually
(if the kernel can't work it out, the application certainly isn't likely
to be able to, and your average human certainly doesn't want to be involved).

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

Yes, of course, but the question is what is better.   I think IPv6 is better
than IPv4 regardless of how source address selection is specified.

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

You mean it has become a router.   That means it has started sending RAs.
That means it has to be ready to forward packets for nodes that observe the
RAs that have been sent, and ...

  | Then it downloads its configuration.

Yes.  Sure.   I'm sure we'd all be happy to run routers that follow
that boot up sequence.   Thanks all the same, but the routers I use
will fetch their (complete) configuration, and only then become a
router - until everything is fetched, the box is a multi-interface host.

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

I would expect that routing protocols will do that, they're one of the
few applications that actually cares.   But routing protocols weren't the
applications I had in mind here - the configuration will be fetched by
tftp, or ftp, or something like that usually, and while inside the router
which is still a host, the precise point down the stack where the source
address is set is pretty much irrelevant, I think it makes a nonsense of
the requirement if the solution is "pick your source address at line 100
rather than line 200, because if you do it at line 200 you have violated
the RFC, where at line 100 you haven't..."

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

Because I want the replies to get to me, and with unidirectional interfaces
there's no guarantee that anyone is necessarily going to be able to route
to a send-only interface.   In fact, if you're doing strict strong model
stuff (which is an option, even if semi-strong is the common case) I would
think that is pretty much essential.

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

No, it isn't.   The IETF could make a standard that mandates the source
address of packets, and simply not allow applications to set the address.
If there's really a good reason to restrict what the source address should
be, that's really what should be being done.   That's entirely testable.

On the other hand, I see little point in specifying how source addresses
MUST be set by the kernel, if all that means is that application developers
have to invent an /etc/ipv6-source-address file that they read, and then set
the source address based upon what is in that file instead of allowing the
kernel to do it.   What gain could that be to anyone.

That's why writing down "this is how we think source addresses should be
selected" is a fine idea, but pretending to conditionally mandate it is
silly.   You MUST do it this way .. unless you don't want to!

And all of this is one of the reasons that the IETF has generally avoided
doing any kind of API specs.

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

Yes.

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

Yes.   All of these might be relevant.   I don't think we know for sure yet.

So perhaps the best solution is to simply stop attempting to mandate
anything in this area (after all, it doesn't really affect either how
the network works, or how one writes applications, so the benefits have
to be small at best).

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

It isn't certain, that's true.

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

Yes, though in that circumstance I'd like to believe that the nodes will
detect that, and use a link local destination address as well.  I believe
that can be automated (without DNS foolishness), and have been meaning to
write down how it can be done.

  | I also have some thoughts on "unnumbered interfaces". I still can't see that
  | they are actually useful for v6.

Fully unnumbered, yes, I agree, but interfaces with only limited scope
I believe can be.

  | IPv6 has plenty of address space. It's the big feature.

Yes, I know.

  | Tunnels can be given /126s.

Yes, then can, but out of whose address space does that /126 come?

One of the reasons for the use of unnumbered links (which predates the
real pressure on IPv4 addresses incidentally - ie: they weren't invented
as an address conservation measure) is that you really don't want the
link between two sites to be using address space from either of them.
This is out of my field, but I think it complicates routing and boundary
case issues.   That explains all of the DMZ type class C nets that abound.
While buring /126s for inter-site links is probably a reasonable thing to
do, buring /48s most likely isn't.

That seems to apply only to routers, but doesn't really (and in any case
the router/host distinction in this area I dimply don't believe).

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

If "unnumbered" interfaces have to be "made to work" then yes, that would be
true.   On the other hand, if unnumbered interfaces "just work", then the
advantages of not needing to race around picking subnet numbers, etc, would
seem to be the easier (simpler) case.

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

Not true.

  | So my conclusion so far for modifying the draft is:

That isn't what I would do.

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: Jim Bound <[email-masked]>
Date: Mon, 01 Nov 1999 09:48:50 -0500

Hi Rich,

Just listening to all the chatter.....on the draft... which is good..

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

It already is now but this makes it better.

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

Well I for one don't care if its a standard.  getipnodebyname and
friends are not standards but we are all implementing them for
interoperability.  src addr select is the same thing.  As far as I am
concerned your draft goes to the top of things to write code for on IPv6
today.   But I do think standardizing this is a good idea but we may
need to make it a BCP, I think we need guidance from the chairs here?

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

Scope should be included but we know so little about it as carpenters
building IPv6.  But we need it.

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

They must live they exist in the architecture and permitted.

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

Well as you see the forwarding btw interfaces is being discussed now.
For now I agree with Steve that the standard permits such behavior,
whether we change that is TBD based on the discussion.  I don't see the
harm of it being in the architecture from the mail just yet but
listening.

So you need to keep it in the spec is my feeling until the WG decides
its not part of the architecture, Sam's mail brought up the most
undesirable property and one we need to think about.

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

Yes.  I was going to let this go and just implement it.  This was my
issue with 6to4 mandating longest match but it appears no one was
listening so I did not throw in the issue of "scope", which I had to
deal with big time for the base api.

/jim