Hi Fred,
How do you see RANGER fitting into the requirements for carriers to supply
IP support (v4/v6) to mobile devices? Especially requirements that are
similar to the enterprise ones that you describe?
Eric
Templin, Fred L writes:
This message is to introduce a new Internet-Draft title
This may seem a little petty, but based on the abstract and title of this
one, shouldn't the line
Updates/Obsoletes/SeeAlso:None
be changed from none to 1888?
Eric
> Original Message
> Subject: RFC 4048 on RFC 1888 Is Obsolete
> Date: Fri, 15 Apr 2005 12:20:00 -0700
Mukesh.K.Gupta Wrote:
About the character used, I was in favor of "_" before I
read Brian's comment about "_" being vanishing when the
URI is underlined. Considering the number of places where
URIs are underlined (word underlines the URIs, web pages
underline the URIs etc), I don't think using "_
Antonio Querubin wrote:
Here is what I hope is the final text that specifies the deprecation of
the
"IPv4-compatible IPv6 address". Included below are the revised sections
"IPv6 Addresses with Embedded IPv4 Addresses" and "IANA Consideration".
Please review. I hope to submit an update draft to
(cross posted to IPv6 and V6 Ops)
In case any of you would like to see how some of this is being implemented
here is a nice (free) white paper from Lucent (it is a little vendor
biased, but still valid).
Eric
The Challenges of Next Generation IP Address Management
The concept of managing two
As I recall we had a rather long discussion about this last year. The
conclusions were that in most cases geographical dependencies were more
problems then they were worth. Examples that stuck in my mind had to do with
cruise ships docking at new locations and needing to reregister all
addresses (a
Although I agree that this should be downgraded to historical status, I
would not count on the ATM Forum doing anything with it any time soon as
last week there was an announcement of the planned merger of the ATM Forum
with the MPLS and Frame Relay Alliance.
It seems to me that the new combined o
> p.s. right now, I don't think this issue (if we need to call it an
> issue) is a show-stopper to advance rfc2462bis.
I agree, it was more of a next step question. The document looks good to go
from my point of view.
Eric
- Original Message -
From: )>
To: "
In reviewing this document one question comes to mind from my own personal
experience with IPv4 network and it is related to "zero touch provisioning".
I realize that this is for stateless provisioning, but I still could not see
where this would fall other than here.
Background:
Under the standard
Mark Smith wrote
> > If there are this many new drafts coming out in November 2003, even with
a
> > WG decision to not do NAT IPv6 then there should be a big red flag that
> > there is a disconnect between what this WG says and what others are
doing.
> >
>
> I would prefer to say it the other way .
Tim Chown wrote:
> On Mon, Nov 24, 2003 at 10:03:44AM +0200, EricLKlein wrote:
> >
> > The list of IPv6 plus NAT is over 140 documents long, with many of them
> > being proposed in the last 5 days. The look up list I ran is:
> >
http://search.ietf.org/cgi-bin/htsearch
Brian Haberman wrote:
> I'm curious, have you read draft-ietf-ipv6-unique-local-addr-01.txt?
> The locally assigned prefixes come out of the FD00::/8 range and
> the centrally assigned prefixes come out of the FC00::/8 range. Can
> you explain to me why you think they will collide at some point?
>
Mark Smith wrote
> > I am still have 2 concerns with these concepts:
> > 1. People do not want to register their secure internal network nodes
(bank
> > central computes etc) so the "registered unique local addreses" may not
meet
> > their needs. They do not want to have even theoritically reachabl
Tim Chown wrote
>
> So they can use addresses from the probabilistically unique range under
> the space fd00::/8. There is, in terms of raw usage, no difference
between
> using fd00::/8 or fec0::/10. External networks would still have to route
> the prefixes back to you for you to be reachable,
> Mark Smith wrote
> > I am still have 2 concerns with these concepts:
> > 1. People do not want to register their secure internal network nodes
(bank
> > central computes etc) so the "registered unique local addreses" may not
meet
> > their needs. They do not want to have even theoritically reacha
Christian Huitema wrote:
> Andrew, the draft has provision for both "registered unique local
> addresses" and "probably unique local addresses". The registered unique
> addresses are not valid on the Internet, but they definitely will not
> collide with other addresses.
I am still have 2 concerns
Andrew White wrote
> The problem with these people's arguments is that it's not the address
range
> that gives the security, it's the fact that you have an isolated network
> connected to the global network via only a proxy (NAT) and firewall.
>
> You can use any address range you like inside the N
Margaret.Wasserman wrote
> > I have been speaking to different
> > companies here in Israel, and the basic answer is that if I
> > can not have site locals and NAT then I will not move to IPv6.
> If these people are happy with IPv4 NAT, why would they want
> to move to IPv6? They couldn't need mo
Christian Huitema wrote:
> Frankly, I don't believe that we should worry about net 10 in the site
> local deprecation draft. The site local deprecation document is
> specifically about the prefix 0xFEC0::/10. In any case, such addresses
> are explicitly banned in the IPv6 addressing architecture. S
Stig Venaas wrote:
> I don't think RFC 3493 is a problem. I had a quick look, and all I can
> find is that if getnameinfo() is passed a compatible address, it's
> supposed to extract the IPv4 address and do a lookup on that.
>
> That it describes what should happen when passed a compatible address
up with a lot of congestion and leakage from what used to be
behind NATv4 or just local RFC1918 local site addresses.
>
> Where can I find the NATv6 group? I have a few things I'd like to
> say to them...
It looks like [EMAIL PROTECTED] or [EMAIL PROTECTED] the group working
on the N
up with a lot of congestion and leakage from what used to be
behind NATv4 or just local RFC1918 local site addresses.
>
> Where can I find the NATv6 group? I have a few things I'd like to
> say to them...
It looks like [EMAIL PROTECTED] or [EMAIL PROTECTED] the group working
on the N
I think the most basic RFC one was missed from the list: RFC1918. Especially
since the NATv6 group is probably working under the presumptions that these
addresses, or ones like them, still exist in IPv6.
IETF IPv6 working grou
- Original Message -
From: "Bound, Jim" <[EMAIL PROTECTED]>
One point I would like to make in regards to this item:
> 3. Were the needs of the market considered in the decision? I don't
> think by all but do we ever use this bar? As I said to you once when
> you were on the IESG consi
I have missed a little bit of the converstions about this, so forgive me for
asking what once was a simple question:
What is the current status of geographic location in the IPv6 address? Once
it was part of the standard, is this still true, and if so how or if not
what replaced it.
thanks,
Eric
Pekka,
Unfortunately, if someone had this they probably would have used it to
explain why local addresses should be removed from IPv6.
Since no one was able to produce it then, I doubt it exists now.
But I would love to see it if there is one, as this would help close the
issue, because it would
26 matches
Mail list logo
