Actually, I would say a variation of rule 8:
Rule 8 may be superseded if the implementation has other means of
choosing among source addresses. For example, if the implementation
somehow knows which source address will result in the "best"
communications performance.
- Alain.
For example,an interface has two an addresses, automatic-configured 1000::1/65
and manually-configured 2000::1/64,and 1000::2/64 is the on-link neighbour of
the interface.We send a packet, for example and ICMPv6 echo, with a destination
address of 1000::2 from the interface,then the source addre
another rule 9?
Best regards,
Lawrence
>-Original Message-
>From: Durand, Alain [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, October 25, 2006 10:40 AM
>To: Lawrence Zou; James Carlson; ipv6@ietf.org
>Subject: RE: address selection and DHCPv6
>
>Lawrence,
>
>You have a point...
>For t
Lawrence,
You have a point...
For this to work, we may have to do it after the longest prefix match
rule,
but limit the match to the upper 64 bits.
- Alain.
> -Original Message-
> From: Lawrence Zou [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 24, 2006 10:02 PM
> To: 'James Car
I don't think we should amending rule 7 in such a way.
in fact , i think this will make the rule 8 unworkable.
according to RFC3484,when at last we have two source address
available,both can pass rule1-rule7,then,the rule 8
will chose the longest match prefix.but if we amend rule 7 and prefer
man
I like your rule7bis algorithm.
When RFC3484 was discussed, it was clear that it will need to be
revisited
over time to cover new types of addresses or new use cases.
- Alain.
> -Original Message-
> From: James Carlson [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 24, 2006 3:52
I've done quite a bit of searching over the archives and over various
web resources, but I haven't seen this issue addressed directly.
Apologies if I've just missed it.
RFC 3484 ("Default Address Selection for Internet Protocol version 6
(IPv6)") section 5 gives a set of ordered comparisons for so
Pekka Savola wrote:
On Mon, 23 Oct 2006, Thomas Narten wrote:
or even strongly cautions against using extension headers.
Why? If someone later comes up with a problem, and extension headers
(despite any drawbacks w.r.t. deployed code) seem like the best
answer, we can have a conversation abou
