> "james" == james woodyatt writes:
james> Correct. But remember: I *never* write NAT66 when what I mean
james> is NPTv6. I really did mean NAT66 and not NPTv6.
james> In this scenario, we would number HOMENET domains with 16
james> bits of ULA subnet identifier and 64 bits
On Feb 26, 2013, at 4:33 PM, Cameron Byrne wrote:
> Routing is better?
>
Yes.
> Warning ... my home network includes exactly 1 802.11g AP that cost $50 6
> years ago and effectively is Zero configuration.
>
You think it's zeroconf, but it's using DHCP on both ends. It's not zeroconf,
but it
Sent from ipv6-only Android
On Feb 26, 2013 8:19 PM, "Ole Troan" wrote:
>
> >> Ok. I see it in the charter. I dont find it particularly appealing or
worth a great trade off for the level of complexity involved. Especially if
the tradeoffs require nat66 or something similarly complex
> >
> > Touché
On Feb 25, 2013, at 19:35 , Lorenzo Colitti wrote:
>
> However, the moment you try to use more /64s internally than you have
> externally, stateless NPTv6 doesn't work any more, right?
Correct. But remember: I *never* write NAT66 when what I mean is NPTv6. I
really did mean NAT66 and not NPT
On Feb 25, 2013, at 6:56 PM, Mark Andrews wrote:
>
> In message <1d1732d1-ac03-450a-add2-611f2fb1c...@apple.com>, james woodyatt
> wri
> tes:
>> p3. All this pain can be traded away for the reasonably well-understood pain
>> of NAT66 and a single ULA prefix with a constant 16-bit subnet ident
>> Ok. I see it in the charter. I dont find it particularly appealing or worth
>> a great trade off for the level of complexity involved. Especially if the
>> tradeoffs require nat66 or something similarly complex
>
> Touché.
>
> Seriously, though, the point of routing in the home is that you r
On Feb 26, 2013, at 1:01 AM, Cameron Byrne wrote:
> Ok. I see it in the charter. I dont find it particularly appealing or worth a
> great trade off for the level of complexity involved. Especially if the
> tradeoffs require nat66 or something similarly complex
Touché.
Seriously, though, the po
Sent from ipv6-only Android
On Feb 26, 2013 1:54 PM, "Cameron Byrne" wrote:
>
> Sent from ipv6-only Android
>
> On Feb 26, 2013 11:53 AM, "Lorenzo Colitti" wrote:
> >
> > On Tue, Feb 26, 2013 at 12:46 PM, Ted Lemon wrote:
> >>
> >> > The alternative is basically a vicious circle: if ISPs ignore
Sent from ipv6-only Android
On Feb 26, 2013 11:53 AM, "Lorenzo Colitti" wrote:
>
> On Tue, Feb 26, 2013 at 12:46 PM, Ted Lemon wrote:
>>
>> > The alternative is basically a vicious circle: if ISPs ignore the
IETF's advice and assign a /64 because they see additional address space as
an upsell opp
On Tue, Feb 26, 2013 at 12:46 PM, Ted Lemon wrote:
> > The alternative is basically a vicious circle: if ISPs ignore the IETF's
> advice and assign a /64 because they see additional address space as an
> upsell opportunity, then someone will figure out how to share the /64 by
> using ugly hacks l
On Feb 25, 2013, at 10:35 PM, Lorenzo Colitti wrote:
> The alternative is basically a vicious circle: if ISPs ignore the IETF's
> advice and assign a /64 because they see additional address space as an
> upsell opportunity, then someone will figure out how to share the /64 by
> using ugly hacks
On Tue, Feb 26, 2013 at 11:22 AM, james woodyatt wrote:
> p1. I don't believe it's reasonable to assume that service providers will
> always provide a short enough prefix to number all the links in a
> subscriber's network, or that those that currently do will continue to do
> so into the foresee
In message <1d1732d1-ac03-450a-add2-611f2fb1c...@apple.com>, james woodyatt wri
tes:
> p3. All this pain can be traded away for the reasonably well-understood pain
> of NAT66 and a single ULA prefix with a constant 16-bit subnet identifier spa
> ce, where collisions will be rare and stateless pre
On Feb 25, 2013, at 16:28 , Lorenzo Colitti wrote:
> On Tue, Feb 26, 2013 at 4:21 AM, james woodyatt wrote:
>> As a result, it means that Automatic Prefix Management here is basically
>> unable to do it statelessly, i.e. by randomly generating subnet numbers from
>> an identifier space of conve
On Tue, Feb 26, 2013 at 4:21 AM, james woodyatt wrote:
> As a result, it means that Automatic Prefix Management here is basically
> unable to do it statelessly, i.e. by randomly generating subnet numbers
> from an identifier space of conventional size and testing for collision
> before using them
On Feb 25, 2013, at 11:21 AM, james woodyatt wrote:
> Basically, we've given up on stateless router autoconfiguration in HOMENET,
> and we're forced into a stateful solution. There are no good choices here,
> and the worst case outcome is that we will force the widespread adoption of
> NAT66
On Feb 23, 2013, at 14:24 , Fred Baker (fred) wrote:
>
> One: the v6ops result reflects the operational result in the ARIN community:
> operators there would like to be able to allocate /56 prefixes to smaller
> customers and /48s to larger ones. If you want castigate someone, castigate
> them
Hi James,
At 13:11 22-02-2013, james woodyatt wrote:
When there was still a consensus that subscribers should always get
a /48 prefix, it was reasonable to expect that a randomly chosen
16-bit subnet identifier would be unlikely to collide with another
subnet in most automatically numbered rout
On Feb 22, 2013, at 1:11 PM, james woodyatt wrote:
> On Feb 22, 2013, at 06:16 , Michael Richardson wrote:
>>
>> If the ISP with the longest prefix is alive first, then the routers
>> pick subnet-id parts that fit into that. If that ISP has provided
>> enough subnets, then even when another
It might be a sidetrack on the discussion but I'll answer anyway
On Fri, Feb 22, 2013 at 10:11 PM, james woodyatt wrote:
> On Feb 22, 2013, at 06:16 , Michael Richardson wrote:
>>
>> If the ISP with the longest prefix is alive first, then the routers
>> pick subnet-id parts that fit into that.
On 22/02/2013 16:54, Fred Baker (fred) wrote:
...
> BTW, a side-note on the issue of non-volatile memory. The OSPF autoconfig
> draft says that an allocated prefix MUST be stored in non-volatile memory and
> as a result survive a reboot. Speaking for myself, I don't see the need for
> that; I'm
On 22/02/2013 21:11, james woodyatt wrote:
> This problem is precisely why I campaigned bitterly and vigorously against
> the adoption and V6OPS and later the publication of RFC 6177.
>
> When there was still a consensus that subscribers should always get a /48
> prefix
I think you must have m
On Feb 22, 2013, at 06:16 , Michael Richardson wrote:
>
> If the ISP with the longest prefix is alive first, then the routers
> pick subnet-id parts that fit into that. If that ISP has provided
> enough subnets, then even when another ISP comes along, the "xx23"
> part might remain stable for a
On Feb 23, 2013, at 3:18 AM, Michael Richardson
wrote:
> Can you elaborate the scenario where a subnet-id renumbering would be
> desireable, and would we want to actually signal this situation explicitly?
There is a BAA (a request for a research proposal) from the US Air Force for a
technolo
> "fred" == fred > writes:
fred> If you would like I can change
fred> This prefix is chosen at random, but may not collide with any
fred> prefix currently advertised within the network and therefore
fred> in the LSP database.
fred> to read
fred> In the absence of ot
On Feb 23, 2013, at 3:16 AM, Michael Richardson
wrote:
>
>> "Lorenzo" == Lorenzo Colitti writes:
>>> I.e. the "0123" is identical for the two prefixes?
>>>
>
>Lorenzo> In the general case where the prefixes assigned by the
>Lorenzo> operators are of different lengths, it cannot
> "fred" == fred > writes:
fred> my draft that if the autoconfig prefix is withdrawn, I expect
fred> prefixes dependent on it to be withdrawn, and if stored in
fred> permanent storage, erased. The implication is that if the same
fred> prefix is then readvertised, there's a goo
> "Lorenzo" == Lorenzo Colitti writes:
>> I.e. the "0123" is identical for the two prefixes?
>>
Lorenzo> In the general case where the prefixes assigned by the
Lorenzo> operators are of different lengths, it cannot be. Right?
True.
If the ISP with the longest prefix is ali
On 22/02/2013 04:50, Fred Baker (fred) wrote:
> On Feb 22, 2013, at 1:54 PM, Michael Richardson
> wrote:
>
>> For a network where there is more than one ISP, is it
>> acceptable for a CPE that has decided that it is
>> PREFIX1:0123::/64, to "randomly" decide to be
>> PREFIX2:0123::/64?
>
> I don
On Feb 22, 2013, at 1:54 PM, Michael Richardson wrote:
> For a network where there is more than one ISP, is it acceptable for a CPE
> that has decided that it is PREFIX1:0123::/64, to "randomly" decide to be
> PREFIX2:0123::/64?
I don't see why not, at least in the home.
There is a case, whi
On Fri, Feb 22, 2013 at 10:31 AM, Michael Richardson
wrote:
> I.e. the "0123" is identical for the two prefixes?
>
In the general case where the prefixes assigned by the operators are of
different lengths, it cannot be. Right?
___
homenet mailing list
h
{possible resend}
Fred,
wrt: draft-baker-ipv6-isis-automatic-prefix-00
for a network where there is more than one ISP, is it acceptable for a CPE
that has decided that it is PREFIX1:0123::/64 (and gone through the
process of advertising it and backing things off...), to "randomly"
decide to be
32 matches
Mail list logo
