There was some discussion on arin-ppml regarding ULA-C which led to talking
about NAT and it's role.
One point that rose out of that discussion is that most consumers will
presume, because they have NAT today, some kind of stateful firewall in
their shiny new IPv6 router. Section 3.1 of the curre
On Mar 25, 2010, at 5:44 PM, Mark Smith wrote:
>>
>> Alternatively, we could continue to ignore the real world.
>>
>
> Well, I live in that operator world too. Just because things have been
> done in the past incorrectly doesn't justify making it acceptable. They
> can be considered as "IPv4 t
On Fri, 26 Mar 2010 10:25:42 +1300
Brian E Carpenter wrote:
> On 2010-03-26 08:00, Lorenzo Colitti wrote:
> > On Thu, Mar 25, 2010 at 2:53 AM, Mark Smith <
> > i...@69706e6720323030352d30312d31340a.nosense.org> wrote:
> >> One should note that [ADDRARCH] specifies universal/local bits (u/g),
>
On Mar 25, 2010, at 5:25 PM, Brian E Carpenter wrote:
> On 2010-03-26 08:00, Lorenzo Colitti wrote:
>> On Thu, Mar 25, 2010 at 2:53 AM, Mark Smith <
>> i...@69706e6720323030352d30312d31340a.nosense.org> wrote:
>>> One should note that [ADDRARCH] specifies universal/local bits (u/g),
>>> which a
On 2010-03-26 08:00, Lorenzo Colitti wrote:
> On Thu, Mar 25, 2010 at 2:53 AM, Mark Smith <
> i...@69706e6720323030352d30312d31340a.nosense.org> wrote:
>> One should note that [ADDRARCH] specifies universal/local bits (u/g),
>> which are the 70th and 71st bits in any address from non-000/3 rang
Hi Lorenzo,
On Thu, 25 Mar 2010 12:00:58 -0700
Lorenzo Colitti wrote:
> On Thu, Mar 25, 2010 at 2:53 AM, Mark Smith <
> i...@69706e6720323030352d30312d31340a.nosense.org> wrote:
> >
> > One should note that [ADDRARCH] specifies universal/local bits (u/g),
> > which are the 70th and 71st bits
On Thu, Mar 25, 2010 at 2:53 AM, Mark Smith <
i...@69706e6720323030352d30312d31340a.nosense.org> wrote:
>
> One should note that [ADDRARCH] specifies universal/local bits (u/g),
> which are the 70th and 71st bits in any address from non-000/3 range.
> When assigning prefixes longer than 64 bi
You can use unrelated addresses at each end if you use RA w/PIO's to
inject on-link prefixes in the Prefix Lists on both routers.
Thanks,
- Wes
Wes Beebee
Software Engineer
Product Development
wbee...@cisco.com
United States
Cisco.com - http://www.cisco.com
For corporate legal information go to
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance Working Group of the IETF.
Title : IPv6 Subnet Model: the Relationship between Links and
Subnet Prefixes
Author(s) : H. Singh, et al.
>-Original Message-
>From: sth...@nethelp.no [mailto:sth...@nethelp.no]
>Sent: Thursday, March 25, 2010 3:13 AM
>To: i...@69706e6720323030352d30312d31340a.nosense.org
>Cc: Hemant Singh (shemant); ra...@psg.com; nit...@juniper.net;
ipv6@ietf.org; lore...@google.com
>Subject: Re: router vs.
> I'd like to understand why SONET links don't use ND. Are there any
> references to operating IPv6 over SONET that explain why ND can't be
> enabled?
A SONET/SDH link is a real point to point link. Which means that in
principle you can use totally unrelated addresses at each end of the
link. Ther
On Wed, 24 Mar 2010 17:47:09 -0500
"Hemant Singh (shemant)" wrote:
> Hey folks,
>
>
>
> It's not that an IPv6 home router has one WAN interface acting as a
> router while another interface on the home router is a host. The
> problem is also not about a home router or a router sitting in the
On Wed, 24 Mar 2010, Erik Nordmark wrote:
Based on what I said at the mike, here is some suggested text to add to the
security considerations section:
Some network devices such as switches might have mechanisms to block ports
from being having a DHCPv6 server, which provides some protect
Hi Hemant,
On Mar 22, 2010, at 4:14 PM, Hemant Singh (shemant) wrote:
It is well-known by now that you needed to modify ND (RFC 4861) for
your network. Now that you are looking into DHCPv6 for address
acquisition and obtaining other parameters, here is some feedback on
the DHCPv6 front.
14 matches
Mail list logo