The IESG has approved the following document:
- 'Distributing Address Selection Policy using DHCPv6'
(draft-ietf-6man-addr-select-opt-13.txt) as Proposed Standard
This document is the product of the IPv6 Maintenance Working Group.
The IESG contact persons are Brian Haberman and Ted
Hi Lorenzo,
The current text describes the meaning of "stale" as follows in 3.2.
The received information can be considered stale in several cases,
e.g., when the interface goes down, the DHCP server does not respond
for a certain amount of time, and the Information Refresh Time is
ex
On Fri, Sep 6, 2013 at 9:23 PM, Tim Chown wrote:
> > If #2, then perhaps this option needs a lifetime value? Unless the plan
> is that a) who/whatever solves the problem statement in RFC 4076 will solve
> this too, or b) that everyone needing this option will use stateful DHCPv6.
>
> What about u
On 6 Sep 2013, at 12:13, Lorenzo Colitti wrote:
> Not sure if it's too late to fix this, but I happened to notice this text in
> draft-ietf-6man-addr-select-opt-11:
>
> "When the information from the DHCP server goes stale, the policy received
> from the DHCP server SHOULD be deprecated."
>
>
Not sure if it's too late to fix this, but I happened to notice this text
in draft-ietf-6man-addr-select-opt-11:
"When the information from the DHCP server goes stale, the policy received
from the DHCP server SHOULD be deprecated."
Unfortunately, as RFC 4076 points out, information received via s
The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'Distributing Address Selection Policy using DHCPv6'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. P
A new Request for Comments is now available in online RFC libraries.
RFC 6724
Title: Default Address Selection for Internet
Protocol Version 6 (IPv6)
Author: D. Thaler, Ed.,
R. Draves,
A
The IESG has approved the following document:
- 'Default Address Selection for Internet Protocol version 6 (IPv6)'
(draft-ietf-6man-rfc3484bis-06.txt) as Proposed Standard
This document is the product of the IPv6 Maintenance Working Group.
The IESG contact persons are Brian Haberman
The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'Default Address Selection for Internet Protocol version 6 (IPv6)'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on t
as the source address in this situation.
I haven't fully thought it through, however I don't think there would
be any different behaviour if the SLAAC and static addresses were from
within different /64s. If both addresses end up being chosen as
candidate source addresses via the curre
On 13 Nov 2010, at 22:24, Mark Smith wrote:
>
> RFC3484, and the draft-ietf-6man-rfc3484-revise-01 update, don't seem to
> specify that preferred lifetime values should be used as a tie-breaker
> with all other things are equal. The only related text I can see in
> RFC3484 is -
>
> 'Rule 3: Avo
Hi,
Geert Hendrickx has posted the following, regarding Linux preferring
most recently updated SLAAC addresses over statically assigned
addresses for source addresses, from within the same /64 prefix, even
thought the preferred lifetime of the static address would be
infinite, and therefore greate
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
ut, your suggestion of Rule 4.5 does more than de-prioritization
of 6to4 prefix.
Rule 4.5: Avoid next-hops that have assigned candidate source
addresses whose labels do not match Label(D).
>> As you mention it, I think the simplicity came from modularization
>> of destination address
ive
routers by default.
Besides, a large majority of the 6to4 routers on the internet today are
indeed unwanted and cause very bad results for people like me that want
to deploy IPv6 services in a reliable manner.
> As you mention it, I think the simplicity came from modularization
> of destinat
Hi Tore,
On 2010/11/07, at 19:56, Tore Anderson wrote:
> * Arifumi Matsumoto
>
>> As I said, prioritization between IPv4 and IPv6 is a matter of
>> destination address selection, which my suggestion does not have any
>> effect on. Usually, native IPv6 is
* Arifumi Matsumoto
> As I said, prioritization between IPv4 and IPv6 is a matter of
> destination address selection, which my suggestion does not have any
> effect on. Usually, native IPv6 is preferred over IPv4 in a
> environment that you assume here.
>
> In a situa
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:
>>
>>
oblematic
>> 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 rule assumes that the next-hop selection (rule 5) is already
>> perfor
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
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
> assigne
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.
Hi,
On 07/28/10 05:44, Arifumi Matsumoto wrote:
The three main points were:
- as the delivering protocol, DHCP should be the most appropriate choice,
> considering the target environments.
I consider DHCP an appropriate choice. However, there have been
concerns that the DHCP packet size w
n points.
>> Though it was decided to discuss more about this issue of address selection
>> at this mailing list, I'd like to see to how much extent those suggestions
>> were accepted by the 6man people *now*.
>>
>> This is important, because not delaying the
Since I wasn't in Maastricht, let me give some quick answers:
On 2010-07-28 17:44, Arifumi Matsumoto wrote:
> Hi,
>
> At the yesterday's 6man session, the design team suggested three main points.
> Though it was decided to discuss more about this issue of address select
Hi,
At the yesterday's 6man session, the design team suggested three main points.
Though it was decided to discuss more about this issue of address selection at
this mailing list, I'd like to see to how much extent those suggestions were
accepted by the 6man people *now*.
This is
All,
I'm writing this e-mail representing the address selection design team.
We've worked and discussed much within the design team, and are
about to make important choices to move forward.
Our main draft revised this week covers whole issues, so I'd like
you to review it.
draft
Hi,
a series of address selection related documents were updated.
Brief description for each documents are below.
* Solution approaches for address-selection problems
http://tools.ietf.org/html/draft-ietf-6man-addr-select-sol-03
This summarizes several solution approaches for the problem
wide 3484 policy distribution work, and make rapid trial-and-error
> work. Neither one alone meets the need.
Same here.
Kindest regards,
> To this day, there are still
>> applications that won't even try to fall-back from IPv6 to IPv4. Also, as
>> you mention, this simply
Hi,
>>>
>>> Missing a Pro that I consider significant:
>>>
>>> - Users will no longer experience multi-second connection
>> delays due
>>> to IPv6's address selection. This means more users will
>>> leave IPv6 ena
Let me re-send the following e-mail.
It did not make it to 6man ml web archive.
---
Hi,
>>>
>>> Missing a Pro that I consider significant:
>>>
>>> - Users will no longer experience multi-second connection
>> delays due
>>> to IPv6's ad
elect-...@tools.ietf.org;
> draft-ietf-6man-addr-select-considerati...@tools.ietf.org;
> 'Mohacsi Janos'; 'Fred Baker';
> draft-arifumi-6man-addr-select-confl...@tools.ietf.org
> Subject: Re: Discussion summary and next-step Re: Thoughts on
> address selection
.org;
> draft-ietf-6man-addr-select-considerati...@tools.ietf.org;
> 'Mohacsi Janos'; 'Fred Baker';
> draft-arifumi-6man-addr-select-confl...@tools.ietf.org
> Subject: Re: Discussion summary and next-step Re: Thoughts on
> address selection
>
> Dan,
&g
e meets the need.
Brian
To this day, there are still
> applications that won't even try to fall-back from IPv6 to IPv4. Also, as
> you mention, this simply doesn't fly for connection-less protocols. So
> IMHO, source address selection should be hidden from apps into the
>
d incorrectly in many apps, and
it won't be implemented at all in others. To this day, there are still
applications that won't even try to fall-back from IPv6 to IPv4. Also, as
you mention, this simply doesn't fly for connection-less protocols. So
IMHO, source address selection shou
Dan,
thank you for your comments.
My responses below.
>>
>> Hi,
>>
>> let me summarize the discussion we had about address selection,
>> and move on to the next-step.
>>
>> The discussion was about a try-and-error based mechanism proposed
>>
On Jan 15, 2010, at 8:07 AM, Dan Wing wrote:
Missing a Pro that I consider significant:
- Users will no longer experience multi-second connection delays due
to IPv6's address selection. This means more users will
leave IPv6 enabled.
To me, that's the big issue. The point
dr-select-considerati...@tools.ietf.org;
> Mohacsi Janos; Fred Baker;
> draft-arifumi-6man-addr-select-confl...@tools.ietf.org
> Subject: Discussion summary and next-step Re: Thoughts on
> address selection
>
> Hi,
>
> let me summarize the discussion we had about address select
Hi,
let me summarize the discussion we had about address selection,
and move on to the next-step.
The discussion was about a try-and-error based mechanism proposed
by Fred Baker, and the address selection design team's proposal,
which is based on policy distribution.
* Fred's pro
ols.ietf.org;
> IETF IPv6 Mailing List; Mohacsi Janos;
> draft-arifumi-6man-addr-select-confl...@tools.ietf.org
> Subject: RE: Thoughts on address selection
>
>
> On Tue, 1 Dec 2009 22:19:10 -0800, "Dan Wing" wrote:
>
> >> I'm a bit worried
Rémi Denis-Courmont allegedly wrote on 12/02/2009 5:17 AM:
> On Tue, 1 Dec 2009 22:19:10 -0800, "Dan Wing" wrote:
>> Are there servers that don't use SYN-cookies now-a-days?
>
> IIRC, recent Linux kernel version have SYN-cookies disabled by default as
> they were found to make things often worse
On Tue, 1 Dec 2009 22:19:10 -0800, "Dan Wing" wrote:
>> I'm a bit worried about this. If e.g. the host is 100ms (RTT) away and
>> 10 combinations work, you may end up creating TCP state (and getting
>> syn-acks back) on the destination host for 10 connections,
>
> Are there servers that don't us
v6
> Mailing List;
> draft-ietf-6man-addr-select-considerati...@tools.ietf.org;
> Mohacsi Janos; draft-arifumi-6man-addr-select-confl...@tools.ietf.org
> Subject: Re: Thoughts on address selection
>
> Fred Baker wrote:
> >
> > On Nov 18, 2009, at 6:22 PM, Arifumi Matsu
Brian,
On 2009/11/21, at 7:02, Brian E Carpenter wrote:
>
> ...
>>> My second point is that assumptions like "the best path is through a
>>> prefix we both use" are silly. Analysis of a common traceroute will
>>> show that two random users tend to use two random ISPs. So a routing
>>> policy tat
host/stack level or in the application.
Ffor the decent pair first can we use the updated RFC 3484 source address
selection.
I believe most TCP applications don't specify source addresses. Some
might store which destination address they successfully connected to
though. If the applic
Brian E Carpenter wrote:
...
My second point is that assumptions like "the best path is through a
prefix we both use" are silly. Analysis of a common traceroute will
show that two random users tend to use two random ISPs. So a routing
policy tat starts from "assume both users are using the same
...
>> My second point is that assumptions like "the best path is through a
>> prefix we both use" are silly. Analysis of a common traceroute will
>> show that two random users tend to use two random ISPs. So a routing
>> policy tat starts from "assume both users are using the same prefix"
>> is a
Fred Baker wrote:
On Nov 20, 2009, at 1:16 PM, Stig Venaas wrote:
My point is that if say the spacing is 10ms and the RTT is 100ms, you
will needlessly be trying many pairs (up to 10) before you realize that
perhaps the first you tried actually works.
My first point is that if you don't wait
On 2009-11-20 21:06, Fred Baker wrote:
>
> On Nov 20, 2009, at 11:16 AM, Brian E Carpenter wrote:
>
>> If you are polite, and use some sort of exponential backoff like
>> REAP does, the time to discover a working pair can be quite long,
>> unless your first or second guess is correct.
>
> That's
> My second point is that assumptions like "the best path is through a
> prefix we both use" are silly. Analysis of a common traceroute will
> show that two random users tend to use two random ISPs. So a routing
> policy tat starts from "assume both users are using the same prefix"
> is a l
On Nov 20, 2009, at 11:16 AM, Brian E Carpenter wrote:
If you are polite, and use some sort of exponential backoff like
REAP does, the time to discover a working pair can be quite long,
unless your first or second guess is correct.
That's kind of the point of the caching angle...
On Nov 20, 2009, at 1:16 PM, Stig Venaas wrote:
My point is that if say the spacing is 10ms and the RTT is 100ms, you
will needlessly be trying many pairs (up to 10) before you realize
that
perhaps the first you tried actually works.
My first point is that if you don't wait multiple second
Scott Brim wrote:
Stig Venaas allegedly wrote on 11/18/2009 1:44 PM:
Fred Baker wrote:
On Nov 18, 2009, at 6:22 PM, Arifumi Matsumoto wrote:
I guess that is because if you force to try all the pairs, it perfectly
ignores the address selection manner defined in RFC 3484, and thus,
it gives us
On 2009-11-20 15:02, Scott Brim wrote:
> Stig Venaas allegedly wrote on 11/18/2009 1:44 PM:
>> Fred Baker wrote:
>>> On Nov 18, 2009, at 6:22 PM, Arifumi Matsumoto wrote:
>>>
>>>> I guess that is because if you force to try all the pairs, it perfectly
&g
Stig Venaas allegedly wrote on 11/18/2009 1:44 PM:
> Fred Baker wrote:
>>
>> On Nov 18, 2009, at 6:22 PM, Arifumi Matsumoto wrote:
>>
>>> I guess that is because if you force to try all the pairs, it perfectly
>>> ignores the address selection manner defined
s.ietf.org;
draft-ietf-6man-addr-select-considerati...@tools.ietf.org; IETF IPv6 Mailing
List; Mohacsi Janos; draft-arifumi-6man-addr-select-confl...@tools.ietf.org
Subject: Re: Thoughts on address selection
Fred,
On 2009/11/11, at 7:52, Fred Baker wrote:
>
> On Nov 11, 2009, at 2:00 AM, Moh
> On Nov 18, 2009, at 7:43 PM, Arifumi Matsumoto wrote:
>
> > As I wrote in another e-mail, rather than giving over everything to
> > hosts, I think, giving hints for selecting addresses should be
> > reasonable, at least in some environments.
>
> I would very much favor having an icmp messag
Fred,
On 2009/11/18, at 23:07, Fred Baker wrote:
>
> On Nov 18, 2009, at 7:43 PM, Arifumi Matsumoto wrote:
>
>> As I wrote in another e-mail, rather than giving over everything to hosts, I
>> think, giving hints for selecting addresses should be reasonable, at least
>> in some environments.
>
Fred Baker wrote:
On Nov 18, 2009, at 6:22 PM, Arifumi Matsumoto wrote:
I guess that is because if you force to try all the pairs, it perfectly
ignores the address selection manner defined in RFC 3484, and thus,
it gives us not little impact.
If they space them closely and run them in
Brian E Carpenter allegedly wrote on 11/10/2009 9:54 AM:
> Fred,
>
> Another approach to problem 3 is to extract REAP from SHIM6 and
> figure out how to use it to enhance address selection in practice.
... or any mechanism which tests src/dst address pairs. Note that
data packets
On Nov 18, 2009, at 7:43 PM, Arifumi Matsumoto wrote:
As I wrote in another e-mail, rather than giving over everything to
hosts, I think, giving hints for selecting addresses should be
reasonable, at least in some environments.
I would very much favor having an icmp message that the networ
ve all the problems
outside of the site (or subnet, or host). The modest goal could be to
reasonable suggest some source addresses order based on the policy. The
destination address selection - no chance.
Policy definition in the routing currently done by routing protocols (most
notably the BGP)
Fred,
On 2009/11/18, at 18:50, Fred Baker wrote:
On Nov 18, 2009, at 6:43 PM, Arifumi Matsumoto wrote:
I'm not sure we can create perfect-in-every-environment
caching algorithm.
but you're convinced you can design an algorithm that consistently
out-thinks the network design?
IMO, we ca
On 2009/11/18, at 18:46, Fred Baker wrote:
On Nov 18, 2009, at 6:22 PM, Arifumi Matsumoto wrote:
I guess that is because if you force to try all the pairs, it
perfectly
ignores the address selection manner defined in RFC 3484, and thus,
it gives us not little impact.
If they space them
Regarding this way of try-and-error approach,
I think It should be implemented the following way:
for each source address in some order {
create socket
bind (current source address)
for each destination address in some order {
connect (current destinatio
On Nov 18, 2009, at 6:43 PM, Arifumi Matsumoto wrote:
I'm not sure we can create perfect-in-every-environment
caching algorithm.
but you're convinced you can design an algorithm that consistently out-
thinks the network design?
wow. I'm not that optimistic.
On Nov 18, 2009, at 6:22 PM, Arifumi Matsumoto wrote:
I guess that is because if you force to try all the pairs, it
perfectly
ignores the address selection manner defined in RFC 3484, and thus,
it gives us not little impact.
If they space them closely and run them in parallel, I guess I
u would like to have #source_addresses x
#destination address sockets opened. I think it should not be an
issue
"in some order" - ok here we arrived why RFC3484(bis) developed.
Node administrator (or site administrator if RFC3484 can be
propagated via e.g. DHCPv6) can define the ord
connection attempt except that one {
close it
}
}
return the connected socket
There is a similar API in Winsock2 that tries multiple destination
addresses,
but not every pair of destination and source address.
I guess that is because if you force to try all the pairs, it perfectly
i
in the cross-product every K milliseconds until I get
a SYN-ACK
on one of them, and then close all other sessions).
+1
I think what Fred mentioned is the only real way we're going to solve
the address selection problem. If you don't try pairs and select which
one works first, then yo
I get
a SYN-ACK
on one of them, and then close all other sessions).
+1
I think what Fred mentioned is the only real way we're going to solve
the address selection problem. If you don't try pairs and select which
one works first, then you're stuck trying to outguess the networ
...
"in some order" - ok here we arrived why RFC3484(bis) developed. Node
administrator (or site administrator if RFC3484 can be propagated via
e.g. DHCPv6) can define the order. Source address selection is defining
the order!
By the way would like to try with source address as l
On Nov 11, 2009, at 2:00 AM, Mohacsi Janos wrote:
I think this try_and_success_or_failure method can work in most
cases, however it has some burden for implementation and operational
point of view,
It does indeed, at least operationally. That is trivially solved for
sites one frequently
one of them, and then close all other sessions).
+1
I think what Fred mentioned is the only real way we're going to solve
the address selection problem. If you don't try pairs and select which
one works first, then you're stuck trying to outguess the network design
at the operati
sions).
+1
I think what Fred mentioned is the only real way we're going to solve
the address selection problem. If you don't try pairs and select which
one works first, then you're stuck trying to outguess the network design
at the operating system layer. Any approach to do this
On Tue, 10 Nov 2009, Fred Baker wrote:
The simplest solution to (3), if my machine is in an administrative domain
facing an ISP, is to have my DMZ router perform the BCP 38 filter before the
datagram reaches the ISP, and in the failure case reply with some form of
ICMP message that says "routin
Fred,
On 2009/11/10, at 10:42, Fred Baker wrote:
I'm following up on the discussion just had in 6man regarding
address selection. I have this awful feeling that we are fighting
off the alligators and forgetting to drain the swamp.
Correct me if I am wrong. The objectives being the s
ifumi-6man-addr-select-confl...@tools.ietf.org; draft-ietf-
> 6man-addr-select-considerati...@tools.ietf.org; draft-ietf-6man-addr-
> select-...@tools.ietf.org
> Cc: IETF IPv6 Mailing List
> Subject: Thoughts on address selection
>
> I'm following up on the discussion just had
Fred,
Another approach to problem 3 is to extract REAP from SHIM6
and figure out how to use it to enhance address selection
in practice.
Brian
On 2009-11-10 14:42, Fred Baker wrote:
> I'm following up on the discussion just had in 6man regarding address
> selection. I have this aw
I'm following up on the discussion just had in 6man regarding address
selection. I have this awful feeling that we are fighting off the
alligators and forgetting to drain the swamp.
Correct me if I am wrong. The objectives being the source address
selection algorithm are to:
1) k
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
ANY as the effective source address.
The API[3] doesn't specifically state how connect() should choose
the source address in this case. So if the implementation of
connect() went ahead and tried all "CandidateSource(D) addresses"
according to a new address selection algorithm, instead
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
n scope (Thomas)
- noted that multiple interfaces are in scope (Thomas)
- noted node-wide problem is destination address selection (Dave)
- noted the two common multiple interface cases (wired/air, normal/VPN)
- noted any 3484 update has two elements: policy table and algorithms
- noted that many OS
Hi,
just a quick comment.
On 2009/06/18, at 22:59, Aleksi Suhonen wrote:
Hi,
Arifumi Matsumoto wrote:
I found this is a very interesting proposal.
One question.
Thank you. I have one question too:
Should I submit the draft (after I write a bit more of it) for
discussion in Stockholm for
Hi,
Arifumi Matsumoto wrote:
I found this is a very interesting proposal.
One question.
Thank you. I have one question too:
Should I submit the draft (after I write a bit more of it) for
discussion in Stockholm for this WG or for some other WG? And could I
reserve a presentation time slot f
to the address.
Kindest regards,
On 2009/06/15, at 12:02, Aleksi Suhonen wrote:
Hi,
This is a request for comments on a draft for an internet draft on a
new
address selection algorithm that I'm developing as part of the Finnish
Future Internet project. I'm trying to find a ho
Hi,
This is a request for comments on a draft for an internet draft on a new
address selection algorithm that I'm developing as part of the Finnish
Future Internet project. I'm trying to find a home working group for it,
but I'm not finding it easy since it seems to affect
Hi,
The 6man agenda is published at:
http://www.ietf.org/proceedings/09mar/agenda/6man.html
Please note the current version of the address selection draft is -02,
updated from -01, which can be found at:
http://tools.ietf.org/html/draft-chown-addr-select-considerations-02
Thanks,
--
Tim
On Mar 31, 2008, at 10:10 AM, Bob Hinden wrote:
> Fred,
>
>>> I think I am in general agreement of the consequences, but it isn't
>>> about scope, it is about reachability. Anytime there is a a
>>> choice of
>>> addresses to use, the same issue come to play. It's hard to know
>>> about
>>> r
Fred,
>> I think I am in general agreement of the consequences, but it isn't
>> about scope, it is about reachability. Anytime there is a a choice
>> of
>> addresses to use, the same issue come to play. It's hard to know
>> about
>> reachability with out prior knowledge or trying it out and
On 2008-03-29 16:01, Fred Baker wrote:
>
> On Mar 28, 2008, at 12:51 PM, Hemant Singh (shemant) wrote:
>
>> I think I am in general agreement of the consequences, but it isn't
>> about scope, it is about reachability. Anytime there is a a choice of
>> addresses to use, the same issue come to pla
On Mar 28, 2008, at 12:51 PM, Hemant Singh (shemant) wrote:
> I think I am in general agreement of the consequences, but it isn't
> about scope, it is about reachability. Anytime there is a a choice of
> addresses to use, the same issue come to play. It's hard to know
> about
> reachability w
; Brian E Carpenter;
Pekka Savola
Subject: Re: RFC3484 destination address selection rule 2 is buggy
Fred,
>
> On Mar 19, 2008, at 4:56 PM, Brian E Carpenter wrote:
>
>>> - use a ULA source address if and only if the destination is a ULA
>>> in the same prefix
>>
>
Fred,
>
> On Mar 19, 2008, at 4:56 PM, Brian E Carpenter wrote:
>
>>> - use a ULA source address if and only if the destination is a ULA
>>> in the same prefix
>>
>> I think that is broken. There's a reason ULAs are defined as global
>> addresses.
>
> but they are *not* global addresses. If they
On Mar 19, 2008, at 4:56 PM, Brian E Carpenter wrote:
>> - use a ULA source address if and only if the destination is a ULA
>> in the same prefix
>
> I think that is broken. There's a reason ULAs are defined as global
> addresses.
but they are *not* global addresses. If they were, they would b
being unable to get global-scope addresses, yet getting the
default route.
One could say that this is an operational problem but my argument is
that this would be a common-enough scenario that our protocols should
be robust enough to route around this particular failure if there is a
chance
1 - 100 of 250 matches
Mail list logo
