Hi,
* Arifumi Matsumoto
> But, your suggestion of Rule 4.5 does more than de-prioritization
> of 6to4 prefix.
It de-prioritizes 6to4 _routers_ - rule 6 is taking care of
de-prioritizing the 6to4 prefix. All put together, this ensures the
source address selection algorithm selects an a
of rogue 6to4 RA.
But, what matters is if it can always select the best address, or
expected to select the best in most reasonable environment.
> Since next-hop selection is so tightly coupled with source address
> selection I think it makes lots of sense to handle both in RFC 3484.
IMO, it&
ion address selection, route (next-hop) selection, and
> source address selection, brings much benefits to implementing and
> understanding the protocol stack.
>
> So, if you break it, we really have to be careful about its benefits
> and side effects.
I can see that. There's i
gned us SA
> R2) fe80::1 <-- a "proper" router, assigned us SB
>
> The destination address D is a native IPv6 address - say
> 2001:db8:1234::1. Single-stack IPv6 only so the destination address
> selection doesn't come into play.
>
> My understanding of the
next-hops are:
R1) fe80::bad <-- a 6to4 rogue router, assigned us SA
R2) fe80::1 <-- a "proper" router, assigned us SB
The destination address D is a native IPv6 address - say
2001:db8:1234::1. Single-stack IPv6 only so the destination address
selection doesn't come into play
ting
> the best source/destination address pair, you end up pre-empting the
> address table completely. To avoid that I think you have to determine
> the appropriate next-hop _after_ the source/destination address.
The RFC 3484 source address selection rule 5 already makes use of the
in
Hello Arifumi,
* Arifumi Matsumoto
> On a host to which my suggestion is applied,
> if the next-hop is 6to4 advertising host/router, then the source
> address will be 6to4.
> If the next-hop is native IPv6 adverting router, then the source
> address will be native IPv6.
> And, it's depending on w
Hi,
On 2010/10/27, at 16:00, Ole Troan wrote:
>> Off the top of my head, I thought about a new rule to the RFC 3484.
>> It's really a simple rule, and seems to solve several problematic
>> cases related to address selection.
>> The rule is:
>>
>> Prefer to select an address as the source address
Hi,
thanks for sharing your concern.
My comments below.
On 2010/10/31, at 20:31, Tore Anderson wrote:
> Hi,
>
> * Arifumi Matsumoto
>
>> Off the top of my head, I thought about a new rule to the RFC 3484.
>> It's really a simple rule, and seems to solve several problematic
>> cases related to
Hi,
* Arifumi Matsumoto
> Off the top of my head, I thought about a new rule to the RFC 3484.
> It's really a simple rule, and seems to solve several problematic
> cases related to address selection.
> The rule is:
>
> Prefer to select an address as the source address that is
> assigned by t
sel algorithm (*) incorporates this as one of its
base assumptions and as such I'm of course all for it.
However, in the general case it can prove to be very difficult to
actually implement. Source address selection usually happens in the
kernel, but interface address assignment happens
> Off the top of my head, I thought about a new rule to the RFC 3484.
> It's really a simple rule, and seems to solve several problematic
> cases related to address selection.
> The rule is:
>
> Prefer to select an address as the source address that is
> assigned by the selected next-hop.
>
> T
Hi all,
Off the top of my head, I thought about a new rule to the RFC 3484.
It's really a simple rule, and seems to solve several problematic
cases related to address selection.
The rule is:
Prefer to select an address as the source address that is
assigned by the selected next-hop.
This rul
Arifumi Matsumoto wrote:
FYI, I remember M. Bagnulo were working on similar problems
related to source addresse selection mechanism, which is
described in the following expired document.
Thanks, I'll look into that.
> [deleted my own post here]
I'm afraid the latter change for getaddrinfo() mi
Hi,
FYI, I remember M. Bagnulo were working on similar problems
related to source addresse selection mechanism, which is
described in the following expired document.
http://tools.ietf.org/html/draft-bagnulo-ipv6-rfc3484-update-00
further comments below.
This got me thinking, and here are som
Hi,
One of my problems with existing address selection implementations is
that they pick just one source address per destination address. They
never try another source address even if a valid alternative source
address existed for a destination address. This has caused me some
headaches with
Rémi Denis-Courmont;
Thank you for your comments.
At Sun, 2 Dec 2007 03:06:05 +0200,
Rémi Denis-Courmont wrote:
>
> Le Friday 30 November 2007 04:56:58 FUJIKAWA Kenji, vous avez écrit :
> > The downstream interface of router R is assigned both addresses
> > 2001:db8:1001:R and 2001:db8:3001:R.
>
Le Friday 30 November 2007 04:56:58 FUJIKAWA Kenji, vous avez écrit :
> The downstream interface of router R is assigned both addresses
> 2001:db8:1001:R and 2001:db8:3001:R.
> This is required even if R has only a single downstream link.
As your document notes, these is needed *anyway*, because o
Hi all,
In http://www3.ietf.org/proceedings/07dec/agenda/6man.txt ,
> - Address Selection
> * draft-fujikawa-ipv6-src-addr-selection-01.txt Fujikawa 5
> minutes
my slot is allocated.
Thank you very much for allocation, Chairs.
I would like to briefly introduce my draft.
The questio
Dear 6man chairs and members;
I posted an internet draft,
draft-fujikawa-ipv6-src-addr-selection-01.txt
which shows one method of selecting a source address
just from ordinal destination-based routing information.
Can I have just 5 minutes to make a presentation in the
next IETF 6man WG
Hi,
Nicolas Dichtel wrote:
I've a question about source address selection in HAAD Reply message.
...
RUT is a Home Agent and the Home Link is Link0.
This is important.
MN1X sends a HAAD Request message to its home agent (RUT). The
destination address of this message is an anycast ad
;t be used as the source address,
but was removed recently. I forget which spec.
Vijay
Nicolas Dichtel wrote:
Hi,
I've a question about source address selection in HAAD Reply message.
Here is the topology:
Nicolas Dichtel wrote:
Hi,
I've a question about source address selection in HAAD Reply message.
Here is the topology:
MN1X
|
+---+--- Link1X
|
FYI,
--julien
---
A new Request for Comments is now available in online RFC libraries.
RFC 5014
Title: IPv6 Socket API for Source
Address Selection
Author
Hi all,
[Let me re-send this mail. Yesterday my post was returned because
of user-unknown.]
We've submitted a set of revised internet drafts about IPv6 source
address selection policy distribution.
Title : Source Address Selection Policy Distribution for Multihoming
Filename: draft-ar
Hi, all.
I posted the following e-mail to multi6-wg a few days ago.
But I guess many of people in this wg also should have
interests in it. So let me cross-post it to here.
I submitted 3 new I-Ds about Source Address Selection issue.
These will appear on ietf web site soon.
The first one is a
In RFC3484 source address selection is described,
which selects a source address from a candidate
set by defining a total ordering onto the addresses.
Typically (RCOMMENDED) the candidate set consist of just the addresses
assigned to the outgoing interface.
In case that all global addresses
No objection to the proposed resolution, so
the issue is closed. Please revisit the issue
if you have a different opinion.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mai
No objection to the proposed resolution, so
the issue is closed. Please revisit the issue
if you have a different opinion.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mai
29 matches
Mail list logo
