and for VoIP - or you
might not, depending on how you've chosen to use the flow label. Again,
it isn't for the IPv6 WG to legislate on this.
Brian
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards Technology, IBM
NEW
Dan Lanciani wrote:
Tony Hain [EMAIL PROTECTED] wrote:
|That said, there are multiple parts to the isolation issue, and even though
|most NAT implementations combine them, the discussion will be more
|constructive to keep them separate.
I used to believe this, but I recently came to the
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards Technology
Iljitsch van Beijnum wrote:
On 24 okt 2003, at 18:14, Hans Kruse wrote:
2. Several folks stumbled over the wording (in section 1.0) that
applications may treat these address[sic] like global scoped
addresses. How about:
Applications may treat these addresses like global scoped
Formally, no, this could be processed as an independent submission.
But I think review by this WG is desirable anyway. Could the chairs
give it 5 minutes on the agenda? Having written the original faulty
ABNF, I feel some responsibility here...
Brian
Zefram wrote:
[EMAIL PROTECTED] wrote:
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards Technology, IBM
NEW ADDRESS [EMAIL PROTECTED] PLEASE UPDATE ADDRESS BOOK
IETF IPv6 working group mailing list
Geoff,
Geoff Huston wrote:
Brian,
In your note to Alain you pose the question:
Do you think it is better to let the RIRs develop a policy for
allocating PA space for local use, i.e. create a swamp like IPv4?
It appears to me that you see this as being an either / or situation,
where
Well, I agree with Christian's responses. We need to prevent panic
(people rushing to switch off FEC0 immediately) and we need to prevent
people continuing to write code to support it. I find it hard to see
any wording that is better than the current draft. The IETF often
specifies what must or
Yes, correct, and SL-IMPACT must not become a blocking reference.
Brian
Pekka Savola wrote:
On Thu, 6 Nov 2003, Brian E Carpenter wrote:
Pekka, it's been a while, but my recollection is that we (the authors)
didn't agree and didn't see any support for your comments on the list.
I
itojun,
Tim has replied technically.
I would object to this being published as Experimental. That would be
the worst solution, since nobody would have any idea whether it was safe
to use it. I'd rather we simply started misusing PA or, indeed, 6to4
space to solve the operational problem. In
How about simply calling whatever we end up with organizational addresses?
I think that captures it much better than local, site local, private
or whatever.
Brian
Stephen Sprunk wrote:
Thus spake Iljitsch van Beijnum [EMAIL PROTECTED]
1. To number systems/interfaces that are only
networks) operators to extend the same understanding to IPv6.
CP
On Mon, 10 Nov 2003 21:52:46 +0100, Brian E Carpenter
[EMAIL PROTECTED] said:
How about simply calling whatever we end up with organizational
addresses? I think that captures it much better than local, site
local
working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer
Pekka Savola wrote:
On Thu, 13 Nov 2003, Bob Hinden wrote:
So my take is that only the Address Architecture and Default Address
Selection documents need to be listed.
FWIW, totally agree here. Listing those which had no issues of substance
only confuse the reader.
That isn't
Alain Durand wrote:
Zefram wrote:
Alain Durand wrote:
If this is the case, what will we have gained from fec0::/48?
The opportunity to avoid this numbering clash. Idiots who use fd00::/48
will clash with each other, but the rest of us avoid clashes with each
other and with the
While I'd personally love to declare RFC 1918 Historic, it really is
completely IPv4 specific so we have no reason to reference it.
Where can I find the NATv6 group? I have a few things I'd like to
say to them...
Brian
EricLKlein wrote:
I think the most basic RFC one was missed from the
.ietf.org/mailman/listinfo/ipv6
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards Technology, IBM
NEW ADDRESS [EMAIL PROTECTED] PLEASE UPDATE ADDRESS
EricLKlein wrote:
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
EricLKlein wrote:
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
Keith Moore wrote:
I've chewed on this for quite a while, and I think some derivative
of private would be good but a suggestion we heard earlier is
even better. I recall seeing some time back the suggestion of
Organizational Addresses, and I think this fits best of all.
that's
Keith Moore wrote:
To the implementors:
a) don't implement SL if you are designing a new product
b) don't rush removing SL support from your current products, this can
be done in future releases.
to application implementors:
a) avoid using SL addresses in applications that
:
Brian E Carpenter wrote:
Which software release counts as new is indeed not a question for
the IETF, and each implementer will have to make his/her own judgement
about exactly when to remove the feature. But I don't think it's wrong to
say that they MUST remove it.
Sorry- I'm lost
JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:
On Tue, 16 Dec 2003 11:49:47 +0100,
Brian E Carpenter [EMAIL PROTECTED] said:
textual representation
2.2 (1) has to state how many digits are permitted as x
(one component between colon). my personal preference is that
x has
and requiring NATs as a result.
Brian
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards Technology, IBM
*** I will be on vacation February 3-25, 2004 ***
Brian Haberman wrote:
All,
This is the start
://www1.ietf.org/mailman/listinfo/ipv6
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards Technology, IBM
able to choose between things like temporary and
public addresses, which is something which users/applications might care
about. And this is orthogonal to the multihoming aspects.
Erik
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished
In my opinion, Thomas is correct. This is a technical choice, not
a policy choice, and well within the IETF's competence.
(Speaking as co-drafter and co-signer of RFC 2860, among other things.)
Brian
Thomas Narten wrote:
Alain Durand [EMAIL PROTECTED] writes:
On Feb 27, 2004, at 5:23
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards Technology, IBM
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1
be made to be machine verifiable also.
Maybe there is another way, but in any case I
strongly think the fixed charge should be avoided.
And, finally, I assert that the bugs can be
avoided anyway. It doesn't have to be more
than a few hundred lines of code.
Regards,
Charlie P.
Brian E
Alain Durand wrote:
On Mar 9, 2004, at 9:52 PM, Brian E Carpenter wrote:
Yes, I appologise for accidentally resurrecting the fixed charge,
by typing is suggested when my brain was thinking was suggested.
We did indeed all agree to delegate *that* choice to IANA.
This is the part
Margaret Wasserman wrote:
...
SUBSTANTIVE ISSUES:
(1) This draft doesn't mention the reverse DNS tree. Is it expected that
whatever registry assigns these values will also populate the reverse
DNS tree? Or not?
I think it is better to leave this question for a separate document
[EMAIL PROTECTED] wrote:
On 18 March 2004, Pekka Savola wrote:
On Thu, 18 Mar 2004, Ralph Droms wrote:
Is there interest in expending any more of the IETF's resources
reopening a problem for which we have rough consensus on a
solution,
published specifications and running code?
: https://www1.ietf.org/mailman/listinfo/ipv6
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards Technology, IBM
Stephen Sprunk wrote:
Thus spake Bill Manning [EMAIL PROTECTED]
...
actually, I think it is imprudent to not include the
RIR public policy fourm in any discussions on new address
assignment plans. YMMV of course.
I agree and invite input from ARIN members. NOTE: Please include in
Stephen Sprunk wrote:
...
Suggested text for 7.0:
and PTR records for Local IPv6 addresses MAY be installed in the global
DNS at the option of the site to which they are assigned. It is expected
that most sites will not make use of this option, but some sites may find
benefits in
Stephen Sprunk wrote:
Thus spake Brian Haberman [EMAIL PROTECTED]
Margaret Wasserman wrote:
This would appear to be incompatible with the IANA considerations
section that says:
If deemed
appropriate, the authority may also consist of multiple
organizations
Lori Napoli wrote:
Roy Brabson/Raleigh/IBM wrote on 04/22/2004 09:46:15 AM:
The only problematic case, as far as I can see, would be ICMPv6 too
big messages for path MTU discovery. In this case, however, we can
still update the MTU information gradually; we first update the MTU
Alper Yegin wrote:
There was some discussion of this general concept (zero-configuration
routing and/or layer 3 bridging) in the Zerouter BOF and on the
zerouter mailing list... Does anyone know if that effort is still
active?
http://www.ietf.org/internet-drafts/draft-perlman-rbridge-00.txt
JINMEI Tatuya wrote:
[Note: if you've forgotten the discussion, please first refer to the
following URL (and its followups if necessary):
https://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg01797.html ]
In this message, I pointed out that there might be possible conflict
Jinmei, I believe your proposed new text at the bottom is correct.
2462bis should not open the door to conflict in future link-layer
specs.
Brian
JINMEI Tatuya wrote:
On Tue, 18 May 2004 17:46:15 +0200,
Brian E Carpenter [EMAIL PROTECTED] said:
In this message, I pointed out that there might
OK
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards Technology, IBM
JINMEI Tatuya wrote:
On Wed, 19 May 2004 12:16:27 +0200,
Brian E Carpenter [EMAIL PROTECTED] said:
Jinmei, I believe your proposed new text
Architecturally, this appears to be the correct solution.
(I would expect a lot of protest at any proposal to *actually*
deviate from 64 bits, but that is another discussion.)
Brian
JINMEI Tatuya wrote:
On Thu, 20 May 2004 22:14:54 +0900,
JINMEI Tatuya [EMAIL PROTECTED] said:
Jinmei, I
Unfortunately I found another few of points... I can't remember
whether we discussed them before.
Somewhere in section 4 I think we should add something along these
lines:
4.x Special header fields
If a node supports the Traffic Class field, it MUST do so
in accordance with [RFC2474], [RFC 3168],
I'm sorry to come up with a substantive comment late in the day,
since I very much like this document. This isn't a showstopper,
but I though it was worth mentioning:
12.0 Security Considerations
Local IPv6 addresses do not provide any inherent security to the
nodes that use them. They may
Let me be brutal. I think that we are fiddling while Rome burns.
We need this thing to be done, and the draft is good enough
for Proposed Standard. Let's just ship it.
Brian
Tim Chown wrote:
On Fri, Jul 02, 2004 at 09:06:45AM +0930, Mark Smith wrote:
(a) replace site with address domain,
I concur. The split is goodness.
Brian
Margaret Wasserman wrote:
Hi All,
I support the idea of splitting this draft into two portions for several
reasons.
First, some facts as I understand them:
(1) The uncertainty regarding the status of unicast site-local
addressing and its eventual
Dan Lanciani wrote:
|It may be that this issue of assignments performed in perpetuity
|vs fixed period renewable assignments should be a matter of
|choice by the client as the time of assignment, and that charge
|applicable to this service reflect the different cost
Yeah, well, this is IANA's problem, not ours or the IESG's.
I don't think we should spend cycles on it.
Brian
Brian Haberman wrote:
4) We note that if the RIRS are to implement this proposal (or something
like it), there may be RIR-internal processes that need to take
place in order to
Stephen Sprunk wrote:
...
... Given the
inevitability of collisions in the locally-assigned space, it doesn't seem
logical to allow them in the global reverse tree.
There is no inevitability - on the contrary, there is a very low
probability. But I agree with the conclusion, since I don't think
Mark Andrews wrote:
Dan Lanciani wrote:
Brian E Carpenter [EMAIL PROTECTED] wrote:
|But I agree with the conclusion, since I don't think
|either kind of ULA has any business in the global DNS.
Are you including the forward DNS in that statement? I would be opposed
to dicouraging such use since
Arun,
1888 is an Experimental RFC that contains health warnings that it
won't work, and as far as I know nobody has ever attempted to
implement it. There also is some interest in the ATM Forum in the
mapping of IP addresses inside NSAP addresses, but that is another
story.
My opinion as the main
OK. But no promise about when.
I think we will have to leave existing IANA assignments in place,
but I will think a bit more about that.
Brian
Bob Hinden wrote:
Brian,
Without really thinking about it, and with my OSI knowledge having
ten years' rust on it, it seems to me that port numbers
/comments to this draft, suitable way forward as seen
fit could then be taken-up. Anybody from ATM Forum interested in the issue is welcome
to join in.
Regards,
Arun.
-Original Message-
From: Brian Haberman [mailto:[EMAIL PROTECTED]
Sent: Friday, July 30, 2004 7:54 PM
To: Brian E Carpenter
I've read this since I left the microphone. I stick to my guns -
the statement Requests for type value assignments from outside of the
IETF should be sent to the IETF for review. is too vague and needs to
be more specific, as in
should be addressed to the IPv6 WG if it exists or to the IESG if
Sure, if the IESG agrees, this is fine.
Brian
Bob Hinden wrote:
Brian,
At 04:06 PM 08/04/2004, Brian E Carpenter wrote:
I've read this since I left the microphone. I stick to my guns -
the statement Requests for type value assignments from outside of the
IETF should be sent to the IETF
This draft obsoletes the OSI addressing format for IPv6.
Comments welcome.
Brian
Original Message
Subject: I-D ACTION:draft-carpenter-obsolete-1888-00.txt
Date: Mon, 16 Aug 2004 15:18:40 -0400
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
A New
P.S. I'm quite aware that this has already passed the IESG,
but it will obviously have to be updated one day, so please
keep these comments in a safe place.
Brian
Brian E Carpenter wrote:
In section 11.7:
The preferred format for literal IPv6 addresses in URL's are also
defined [12
JINMEI Tatuya wrote:
On Tue, 31 Aug 2004 10:05:33 +0200,
Brian E Carpenter [EMAIL PROTECTED] said:
P.S. I'm quite aware that this has already passed the IESG,
but it will obviously have to be updated one day, so please
keep these comments in a safe place.
I interpret this to mean that you
Jordi,
As you imply, one or more /64 prefixes is in fact completely compatible
with /64 or /48. As one of the culprits behind RFC 3177, I still
believe that once a subscriber needs to subnet, everything will be
much easier if the next step up is *always* a /48. Imagine the mess if
you give 3
Having read the whole thread, I can't see any convincing reason
to include the flow label in AH.
Apart from the arguments already expressed, what do we do if
AH fails because of a changed flow label? We discard the packet
instead of delivering it. Does that improve QOS? I don't *think*
so. On the
Pekka Savola wrote:
...
* I hope the problem statement above justifies the use of privacy
addresses for ULAs
I'm not so sure: so, you'd assume that the evil enterprise
administrator would be eavesdropping and correlating enterprise's
internal traffic, or the enterprise's internal web servers
Suggestion at the end...
Pekka Savola wrote:
On Wed, 20 Oct 2004, Suresh Krishnan wrote:
o An attacker who is in the path between the node in question and
the peer(s) it is communicating to, and can view the IPv6
addresses present in the datagrams.
Pekka Savola wrote:
On Fri, 22 Oct 2004, Suresh Krishnan wrote:
Hi Pekka/Brian,
This is the text I added to have a per-prefix enable/disable
setting. Hope it resolves your issues.
Additionally, sites might wish to selectively enable or disable the
use of temporary addresses for some
+0200
From: Brian E Carpenter [EMAIL PROTECTED]
Organization: IBM
To: IPv6 [EMAIL PROTECTED]
References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED]
Your suggested changes seem fine to me. I certainly don't
think we should recall the draft from the RFC Editor. If the
changes
Looking at the non-trivial bits of the change log:
o Changed the format in section 3.1 in add a L (local/central)
bit and reduced the size of the global-ID to 40 bits. This is
equivalent to the previous separate prefixes and makes the
document clearer.
OK for me
Just as an FYI, draft-carpenter-obsolete-1888-01.txt (Informational)
is in the RFC Editor queue. It obsoletes a former IPNGWG Experimental
RFC.
Brian C
Brian Haberman wrote:
All,
The following URL contains the latest document status for all
IPv6 WG documents. Please review and provide
-site communication.'
I think that is an improvement.
Brian
Tony
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Brian E Carpenter
Sent: Wednesday, November 10, 2004 7:22 AM
To: Jun-ichiro itojun Hagino
Cc: [EMAIL PROTECTED]
Subject: Re: IPv6 ULA
It's
Mark,
I don't think wait and see is a cop-out, actually. Since these
addresses are by definition useless on the Internet in general,
I think local pragmatic decision taking is the best way to find
out what we *should* recommend. It's not obvious to me that
a typical corporate deployment of ULAs
It costs real money to absorb the load.
Well understood. But it will be a while before this goes mainstream.
Brian
Mark Andrews wrote:
Mark,
I don't think wait and see is a cop-out, actually. Since these
addresses are by definition useless on the Internet in general,
I think local pragmatic
Achim,
A localisation seems to be necessary for the Internet,
otherwise so many
people would not work on a localisation for Internet users
(geopriv,ecrit, etc.).
No, this doesn't follow. The fact that there are commercial
motivations for geolocation or possible invasions of privacy
using
projection illustrates by constructing a topology
between the map and the physical world. Whether that topology and a
particular graph have a topological relation is a different matter. A
network in and of itself has no topology.
At 13:50 +0100 12/2/04, Brian E Carpenter wrote:
Achim,
A localisation
Juergen Schoenwaelder wrote:
On Thu, Dec 02, 2004 at 02:42:53PM +0100, Brian E Carpenter wrote:
I have to wonder whether we shouldn't go further, and RECOMMEND
the _ format and deprecate the % format in the scoping architecture.
Annoying for implementers, but then we could get cut-and-paste
Atsushi Onoe wrote:
I agree that getting cut and paste is a big usability win. Does _
create any other problems?
There were 100 e-mails on the ipng ML at December 1999 about the
representation. Actually we considered the all possible characters.
One reason to reject '_' was that it should be
Dan Lanciani wrote:
Mark Andrews [EMAIL PROTECTED] wrote:
|+Advertising locally assigned ULA records in the global DNS is
|+MUST NOT occur as they are not globally unique and will lead
|+to unexpected connections.
I strongly object to making this a MUST NOT, ...
OK. Lot of
How interesting! www.%33com.com also fails, so it isn't even
being kicked into numeric addresses that does it - the parsers
simply don't interpret the escape at that point.
So they're all broken?
Brian
Juergen Schoenwaelder wrote:
On Sun, Dec 05, 2004 at 11:54:07AM -0800, Bill Fenner wrote:
Noritoshi Demizu wrote:
No. As BNF states in RFC 2396, escape by '%' is not allowed for hostport.
So the implementation should not interpret '%33' as '3' when it appears
in hostname or IP address, in any cases.
You might already know but draft-fielding-uri-rfc2396bis-07.txt
allows %xx notation
Bill Manning wrote:
On Dec 6, 2004, at 10:31, Brian E Carpenter wrote:
Dan Lanciani wrote:
Mark Andrews [EMAIL PROTECTED] wrote:
|+Advertising locally assigned ULA records in the global DNS is
|+MUST NOT occur as they are not globally unique and will lead
|+to unexpected
Scott Bradner wrote:
Brian sez:
Bill, you could do that if the prefixes are *routed* but that is
not going to be the case if the ULA spec is followed, except for
private routing arrangements. Since the spec says they MUST NOT
be globally routed,
imo - much wishful thinking
My point is simply
I agree with Bob about the current draft; I still believe
it will be much better to discuss the DNS issues in depth
in a separate (dnsops) document. My piece of text was
intended in that context.
Brian
Bob Hinden wrote:
Hi,
OK. Lot of shouting since this was sent but not much new text.
How
Stephen Sprunk wrote:
...
also imo - this whole idea is a clear and present danger to the Internet
(assuming that IPv6 gets general deployment)
I disagree. The risk of these non-aggregatable prefixes appearing
in the default-free BGP4 table in exchange for lots of money is the same
as the risk of
Bill Manning wrote:
On Dec 7, 2004, at 7:44, Brian E Carpenter wrote:
Bill Manning wrote:
On Dec 6, 2004, at 10:31, Brian E Carpenter wrote:
Dan Lanciani wrote:
Mark Andrews [EMAIL PROTECTED] wrote:
|+Advertising locally assigned ULA records in the global
DNS is
|+MUST NOT occur
[EMAIL PROTECTED] wrote:
Bill, you could do that if the prefixes are *routed* but that is
not going to be the case if the ULA spec is followed, except for
private routing arrangements. Since the spec says they MUST NOT
be globally routed, it seems entirely rational to apply the same
rule to your
Bill, this is my last go on this. Not that I specially want
to leave you the last word, but if you don't get what I'm
saying after all this, it's pointless to continue. Below...
[EMAIL PROTECTED] wrote:
On Wed, Dec 08, 2004 at 11:33:28AM +0100, Brian E Carpenter wrote:
[EMAIL PROTECTED] wrote
[4] FEA0::/10 was previously defined as a Site-Local scoped address
prefix. This definition has been deprecated as of September 2004
[RFC3879].
I think that's a typo for FEC0::/10
As soon as the ULA draft is approved, FC00::/7 can also be marked
as Reserved by IETF.
IANA's
I support this version. Although I don't fully agree with
the concerns expressed by some IESG members, I think this
new version is quite OK, and the quickest way make ULAs
available to networks that need them.
Brian
Brian Haberman wrote:
IPv6 WG,
In order to resolve the last IESG discuss
First, lets keep in mind that this is an Informational document.
I wonder whether Experimental wouldn't send a clearer signal
that there is some doubt about the viability of the solution.
I can see how this could be very useful in certain types of
network environment, and publishing as
fyi, this includes the IPv6 address format (obsoleting RFC 2732).
Brian
Original Message
Subject: STD 66,RFC 3986 on Uniform Resource Identifier (URI): Generic
Syntax
Date: Tue, 25 Jan 2005 17:32:09 -0800
From: rfc-editor@rfc-editor.org
To: ietf-announce@ietf.org
CC:
also seems to be disallowed by the
new RFC.
Paul Wilson
APNIC
Brian E Carpenter wrote:
fyi, this includes the IPv6 address format (obsoleting RFC 2732).
Brian
Original Message
Subject: STD 66,RFC 3986 on Uniform Resource Identifier (URI):
Generic Syntax
Date: Tue, 25 Jan
Alain Durand wrote:
...
The argument that NDproxy will only be used in a certain environments
where SEND is not needed is clearly bogus, The IETF is not about
defining standards for special cases but for the whole Internet.
I disagree as a matter of principle. It is perfectly OK to have
specs
Eric asks a good question.
I think the chances that some implementers will choose to store
IPv4 addresses in IPv6-sized structures is 100%. So I am strongly
of the view that that the IPv4-compatible *format*, i.e. a ::/96
prefix, needs to be reserved and never allocated. Of course, it
should never
Bob Hinden wrote:
Brian,
At 02:25 AM 03/18/2005, Brian E Carpenter wrote:
Eric asks a good question.
I think the chances that some implementers will choose to store
IPv4 addresses in IPv6-sized structures is 100%. So I am strongly
of the view that that the IPv4-compatible *format*, i.e. a ::/96
Furthermore, there is some comparison of the proposals in
ftp://ftp.isi.edu/in-notes/rfc1752.txt
1752 The Recommendation for the IP Next Generation Protocol. S.
Bradner, A. Mankin. January 1995. (Format: TXT=127784 bytes) (Status:
PROPOSED STANDARD)
Brian
Baker Fred wrote:
It's OK in my personal opinion, but I wouldn't object to removing
the may continue to use sentence if that is the consensus.
Brian
Bob Hinden wrote:
Hi,
Here is what I hope is the final text that specifies the deprecation of
the IPv4-compatible IPv6 address. Included below are the revised
Juergen Schoenwaelder wrote:
On Mon, Mar 28, 2005 at 06:20:19PM -0800, Bill Fenner wrote:
0. Should we solve this problem at all?
[...]
1. Should we proceed using _ (or some other non-percent character)?
[...]
2. If not, should we proceed using %25?
[...]
3. If not, should we
I agree that this is the best approach right now.
Brian C
Brian Haberman wrote:
IPv6 WG,
This is a status update on the centrally-allocated ULAs defined in
draft-ietf-ipv6-ula-central-01.txt. At this time the chairs believe it
is prudent to gain operational experience with the
Tim Chown wrote:
On Fri, Apr 15, 2005 at 08:52:26AM +0100, Tim Chown wrote:
On Thu, Apr 14, 2005 at 12:39:25PM -0500, Stephen Sprunk wrote:
I also believe that we should be watching the IPv6 PI policy proposal at
ARIN et al; if the ARIN proposal is approved (and other RIRs follow suit), I
see
It probably should, although the title is fairly clear. 1888 now shows as
Historic in the index. But its true update is presumably going to be
draft-gray-rfc1888bis
Brian
[EMAIL PROTECTED] wrote:
This may seem a little petty, but based on the abstract and title of this
one, shouldn't the line
Firstly, when we were developing RFC 3697, we were told very forcefully
by the WG to remove use cases from the draft and simply to define
generic boundary semantics. I think exactly the same should apply to
this draft, so all the references to 6LSA should be removed. Then we'll
be able to see more
Ran,
You probably need to go through the mail archive and meeting minutes
from the period when RFC 3697 was being developed to find all the
arguments. That was most of 2002 and 2003. But I think the simplest
form of the argument is that it is intended to allow rapid
classification of a packet as
Ran Liebermann wrote:
...
I still see much more benefit in using the Flow Label for 6SLAs.
If this indeed will be a common use for the Flow Label then we should
take into consideration that probably many (if not most) service
providers will not allow their customers to set the Flow Label field
and
1 - 100 of 819 matches
Mail list logo
