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

From: Richard Draves <[email-masked]>
Date: Tue, 2 Nov 1999 13:46:43 -0800

>   | So my conclusion so far for modifying the draft is:
> 
> That isn't what I would do.

We've had a very good discussion, but I think further progress will require
more input and viewpoints from others in the working group. Below I have
some specific responses to a few points.

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

No, until it has finished configuring itself it can send RAs with a zero
router lifetime.

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

The routing is easy to handle. One possibility is to assign addresses to
both interfaces (the incoming and outgoing unidirectional interfaces) out of
the same prefix and have that prefix be routed to the incoming
unidirectional link.

A strict strong model doesn't work for unidirectional links. It needs to be
relaxed on the sending side and/or the receiving side. I am not proposing a
strict strong model.

Of course this is all hypothetical. No one has put on the table a complete
proposal for how unidirectional links should work. We should not preclude
someone from doing this in the future, and I think the proposed rules in the
draft would let unidirectional links work in fairly natural ways.

>   | 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'll defer to the working group chairs, IESG members, & others with more
standards experience on whether source address selection can be the subject
of a standard and whether such a standard can say MUST to the network layer
but let upper-layers, apps, and administrators override the network layer.

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

But I do think the default address selection rules in hosts could and
probably will have a BIG effect on how the network works.

>   | 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 don't think it can be automated (without increasing the load on the
network by sending test packets). There's no way to tell by inspection of a
destination address whether the destination address is really on-link.
Whether the address matches a prefix in the On-Link Prefix List is just a
hint.

>   | Tunnels can be given /126s.
> 
> Yes, then can, but out of whose address space does that /126 come?

One side or the other, doesn't matter. This is how the 6bone tunnels that I
have right now work.
 
> 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.

It's beyond my expertise too. In any case, I've already agreed that IPv6
should support "unnumbered" interfaces on point-to-point links.

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