(Apologies for the late reply)
On 4 jul 2008, at 15.10, John C Klensin wrote:
--On Friday, 04 July, 2008 10:46 +0200 Kurt Erik Lindqvist
<kurtis@xxxxxxxxxxxx> wrote:
On 3 jul 2008, at 15.57, Jeroen Massar wrote:
On Wed, Jul 02, 2008 at 10:47:53PM -0700, 'kent' wrote:
[..]
However, this last address,
2001:470:1:76:2c0:9fff:fe3e:4009, is not explicitly
configured on the sending server; instead, it is being
implicitly
configured through ip6 autoconf stuff:
Which (autoconfig) you should either not be using on servers,
or you should be configuring your software properly to
select the correct outbound address. (I prefer to use the
autoconfig one for 'management' and using a 'service
address' for the service).
What a shame that's not what's in the RFCs..:-)
Despite the ":-)", I think there is an important question here.
Does it imply that this is a use case from which we should be
learning... and then fixing the RFCs? Or that you believe that
the RFCs are correct and Jeroen's analysis is incorrect?
I hope it doesn't mean "the RFCs ought to govern, even when
reality and experience seem to contradict them".
So, from my POV there are a few issues here.
1) I do understand where the current "last 64 bits are EUId" comes from.
2) Someone (I think it was Keith Moore) said that if the scheme
doesn't work for servers AND hosts (i.e no difference) it's a bad
scheme. I sort of agree with that, but the reason it doesn't work for
servers is simply lack of management tools, and the fact that a lot of
protocols / implementations tend to use addresses rather than names.
2) In operational reality, I have learnt that EUI64 for workstations
and similar hosts in combination with non EUI64 numbers for servers
works quite well and is how I work with deployments. And I have a lot
of respect for operational experience and reality. So yes, I think
this is worth considering. Do I believe such a rule can be written
clearly and get IETF consensus....that is a different question.
Best regards,
- kurtis -
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf