When my link to one of those three ISPs goes down, I have a 1/3 chance
of each outbound connection failing because the return path is broken
(or my other two upstreams do uRPF). I also have a 1/3 chance of each
inbound connection failing until I update DNS to remove the relevant
records
Stephen Sprunk wrote:
Thus spake "Perry Lorier" <[EMAIL PROTECTED]>
Stephen Sprunk wrote:
One of the arguments by the anti-ULA crowd is that if someone is
unable to also get PI space, they will NAT their ULAs to PA space
rather than assigning the PA space to hosts directly
Paul Vixie wrote:
One of the arguments by the anti-ULA crowd is that if someone is unable
to also get PI space, they will NAT their ULAs to PA space rather than
assigning the PA space to hosts directly, because NAT is perceived as
less hassle than renumbering every few months.
i don't understan
Stephen Sprunk wrote:
Thus spake "Brian E Carpenter" <[EMAIL PROTECTED]>
The reference to NATv6 confuses me. There's nothing about ULA-*
that leads to NAT. Users will have PA (or PI for the lucky few) prefixes
for global connectivity. ULA-* is for local use (in the sense that RFC
4864 uses "loc
And actually that is where we seem to be at odds. I fear that ULA-G
will leak.
That's all.
So I might be a bit naive here, but why is this a problem? ISP's that
are worried that they're routers can't deal with ULA addresses in their
DFZ will filter all ULA addresses. ISP's that want ULA's i
james woodyatt wrote:
On 20 Jun 2007, at 15:10, Mark Smith wrote:
On Wed, 20 Jun 2007 11:16:15 -0700 james woodyatt <[EMAIL PROTECTED]> wrote:
I'd be more sympathetic to arguments like this if we RFC 4864 didn't
insist on recommending the deployment of stateful packet filters in
IPv6 that bre
However, I do have some routers with interfaces that need numbering,
and I'd rather avoid renumbering them when I change upstreams. Since
ULA-C is cheap and easy to get, I register myself a block of it, and
use it to number my router interfaces. Since I'd rather my customers
saw DNS name
Bob Hinden wrote:
[trimming this to just the IPv6 w.g.]
We think the question for the IPv6 working group on this topic is does
the working group want to do anything to address the issues raised about
the Type 0 routing header. Possible actions include:
1) Deprecate all usage of RH0
2) Rec
>
> In the big picture, I think that's the direction we need to move.
> But I don't think we want to have every application have that logic,
> since the logic might need to evolve over time (and needs to take into
> account Alain's example of umpteen different IP addresses - might want
> to stagg
>> The Correct Solution(tm) for this entire problem (IMHO) is for Pekka to
>> make sure that the gateway box for the client PC's throws an unreachable
>> error back to the hosts when it realises it can't forward it out to the
>> Internet. The client boxes should detect the unreachable and give up
Rémi Denis-Courmont wrote:
> Le Mercredi 10 Mai 2006 10:35, marcelo bagnulo braun a écrit :
>
>>ulas and private address can be used to reach a global destiantion
>>address heavily depending on the local setup, hence local
>>configuration per case is needed in the general case...
>
>
> This assu
Abhijit Chaudhary (abchaudh) wrote:
> Hi,
> I have question regarding IPv6 auto service discovery.
>
> Suppose a IPv6 Mobile Host comes and joins a network. Using Stateful or
> Stateless Address Configuration mentioned in ICMPv6 Router
> Advertisement message it gets a IPv6 address.
> But if th
Iljitsch van Beijnum wrote:
> On 2-aug-2005, at 17:15, Soohong Daniel Park wrote:
>
>> 2) Other requirements to be considered ?
>
> As someone who gets called when the day-to-day admins can't figure it
> out, I feel it's important that all of this is as predictable as
> possible. That means tha
Mark Smith wrote:
> Hi Iljitsch, Perry,
>
> I'll admit I haven't been fully following your thread of discussion,
> I've been a bit busy on some other things (another reason why I like the
> simple solution - less thinking :-) )
>
> Something to keep in mind for your solution. TCP announces the ma
(Sorry for being late on the replies, been busy recently :)
> When a tunnel is used, there may be many L2 segments (connected by
> L2 switches) with diverse MTUs separating the tunnel endpoints in what
> otherwise appears as a single-hop to L3. And, the set of L2 segments
> will often be different
Templin, Fred L wrote:
>>>And why not NS?
>>
>>Because when A talks to B, you want A to do the MTU discovery
>>and for B
>>to "learn" the MTU too, but you don't want both sending MTU
>>probes, only
>>one of them needs to do so.
>
>
> Disagree - PMTU probing is a unidirectional endeavor since th
[Bugger! Lost the reply I was writing for this! ]
>> Packet rate however starts becoming a problem at faster speeds, at gige
>> it starts becoming a problem for hosts to deal with unless they are
>> careful. And not all networks are fast, 3G networks are becoming more
>> prevalent. We should no
>
> If you enable jumbo frames on end-nodes without a layer 2 infrastructure
> that supports them, then you get what you deserve - a network that won't
> work. The solution of course is go back to standard size frames or buy
> jumbo capable layer 2 infrastructure and enable it. I think it's reall
>>> 1. do not impede 1500-byte operation
>>> 2. discover and utilize jumboframe capability where possible
>>> 3. discover and utilize (close to) the maximum MTU
>>> 4. recover from sudden MTU reductions fast enough for TCP and similar
>>> to survive
>> 5. Must be fully automatic and not require any
> I'd like to suggest a two phased development approach, based on whether
> layer 2 can be assumed to fully support the larger MTUs or not (I think
> the following is also probably a summary of the couple of threads of
> discussion in the emails of the last couple of days) :
>
> (1) Making the as
> I think our requirements are:
>
> 1. do not impede 1500-byte operation
> 2. discover and utilize jumboframe capability where possible
> 3. discover and utilize (close to) the maximum MTU
> 4. recover from sudden MTU reductions fast enough for TCP and similar
> to survive
I'd add to this lis
>> The hole is that there may be an L2 device in the middle which has a
>> lower MTU than the end hosts. The neighbor MTU is an upper bound,
>> but it's not guaranteed to work -- you need to probe to see what
>> really works.
>
>
> (Layer 1 devices can also impose MTU limits.)
>
> It's impo
Bill Fenner wrote:
> I usually think of the small home router configuration problem -
> buy a box, plug it in, it wants you to configure it using a web
> page, and it's probably fe80::1. I don't have any systems in my
> house that have fewer than two non-loopback interfaces. Since
> this is presu
Fred Templin wrote:
Pekka Savola <[EMAIL PROTECTED]> wrote:
I can't figure how ICMPv6 could notice any further data corruption in any
case, so I see no direct justification in *this* spec.)
We are speaking here about the case of the IPv6 layer noticing data corruption
in a received packet and th
24 matches
Mail list logo
