Ed,
Thank you for this it will be very helpful in several arenas I know that
several non-IETF technical groups are looking at how to implement
coexistence in their technologies.
Eric
On Thu, Nov 13, 2008 at 1:01 AM, Ed Jankiewicz <[EMAIL PROTECTED]>wrote:
> more for my own purposes reading thro
Cross posted to several lists
Can we keep the NAT66 discussion to less than WGs at a time?
I am trying to keep up with multiple threads on this and trying to explain
that we do not have a valid requirement for NAT66 defined on any of the
mailing lists (v6OPS, BEHAVE, Softwires, RRG, and now v6).
Does this mean that Microsoft went and got approval for every Windows PC
since XP came out? Or that every PC manufacture (including hand helds and
Windows Mobile cell phones) had to do register too?
Seems a bit extreme to me.
Eric
On 2/29/08, Ed Jankiewicz <[EMAIL PROTECTED]> wrote:
>
> wow. I
On 10/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
> >
> I'm not so arrogant as to claim I am all-knowing. That doesn't help win
> technical arguments. And although I can deal with my own educational
> needs by plodding through RFCs and books etc., that doesn't help me find
> a concise o
On 5/3/07, Jeroen Massar <[EMAIL PROTECTED]> wrote:
> I am sorry if I was unclear. I am on both lists and understand their
> diffrences.
No, you are confusing [EMAIL PROTECTED] with [EMAIL PROTECTED]
They are not the same. The first has nothing to do with the IETF and
can't care much about wha
On 5/1/07, Jeroen Massar <[EMAIL PROTECTED]> wrote:
Eric Klein wrote:
> I have just noticed that this topic seems to be going on simutaniously
> on both the IPv6 and v6OPS mailing lists.
>
> The two threads are not coordinated, but both seem very concerned with
> IPv6
I have just noticed that this topic seems to be going on simutaniously on
both the IPv6 and v6OPS mailing lists.
The two threads are not coordinated, but both seem very concerned with IPv6
Type 0 Routing Header issues.
This is seperate to the rash of Linux related warnings that have come out in
On September 16, 2006 00:26 Iljitsch van Beijnum wrote:
On the other hand, is it good for a standards organization to leave
important technical details unspecified and assume tradition and
interoperability testing will take care of the difference?
I think not, real question is do we want impli
John
I am not trying to anything like NAT. My question does not involve
translation at all.
I understand that NAT is not what you want.
I am interested in improving the hiding capability of "client" nodes on
any network by not autoconfiguring a global-scope address that
incorporates any por
Comment at the end.
John Spence wrote:
So, let me revise my comment, focusing on requirements.
I would like the capability to have an interface construct a link-local
address via some mechanism (EUI-64 from MAC, as an example) as normal,
then configure a privacy address, all without autoconfig
Cross posting this to v6OPs as the whole NAT issue is under discussion that
as part of draft-ietf-v6ops-nap-02.txt
From: "Manfredi, Albert E"
Not sure if this is the right wg for this idea, or for that matter if
I'm suggesting anything new.
A comment yesterday made me wonder why pri
(Cross posting this to IPv6-OPS and IPV6 lists - started on the OPS list)
Does anyone else have additonal items that should be on this list? It will
help with my thesis and we might best address these perceptions in a new
draft as some are addressed in draft-ietf-v6ops-nap-02.txt.
I would be
I want to clarify this on the list. As a way of
thanking people who fill in the survey, I am
committing to sending the final article(s) to anyone who fills in their
e-mail address on the last page.
Thanks again
Eric
-Original
Message-From: Eric Klein
[mailto:[EMAIL
one copy of
this request; I am cross posting to several mailing lists and my personal
mailing list.
Thanks for your help,
Eric Klein, MSc.
Leon Recanati Graduate School of Business
Administration and the Netvision Institute for Internet Studies, Tel Aviv
University
[EMAIL PROTECTED
:
Which country where you are based:
How long you have been based in that country:
I realize that this will not reduce the unknown
countries to zero, but this way I can make more accurate conclusions about who
is represented by this mailing list.
Thanks,
Eric Klein, MSc
Ps. If you have an e
anywhere, and if so how I could access it.
Thanks,
Eric Klein, MSc
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
- Original Message -
From: "JINMEI Tatuya
>
> BTW: the following part of Section 5.5 may have some relevant point:
>
>Creation of global and site-local addresses and configuration of
>other parameters as described in this section SHOULD be locally
>configurable. However, the pr
Ronald Pashby wrote
> One assumption that is being made is that all hosts are trying to
communicate through a
> router. There are many networks that hosts only talk to each other.
Looking at ND tables or
> flows in a router is not viable for these networks.
This is a good point, just look at the
Erik Nordmark wrote:
>
> > I agree that the security issues here are great, and that there is a
need in
> > the Management world for this feature. If you could limit this to an
SNMP v3
> > secure function and not a IPv6 function then maybe we could work this
out
> > within the security concerns of
Tom Petch wrote:
> >
> > > I think that might be a reasonable middle ground. It would still make
it
> > > harder than in IPv4 to explore all hosts, yet one can have e.g. SNMP
> > > access to a local agent on the link that provide this (with
appropriate
> > > SNMP security) to allow remote managemen
Erik Nordmark wrote:
> I think that might be a reasonable middle ground. It would still make it
> harder than in IPv4 to explore all hosts, yet one can have e.g. SNMP
> access to a local agent on the link that provide this (with appropriate
> SNMP security) to allow remote management.
>
> Elsewhe
Brian E Carpenter Wrote
> The point is that (at the ISPs' request) the diffserv model allows
> each ISP along the path to apply a different policy - so a packet
> marked for EF treatment inside one ISP might be marked for AF
> treatment inside another ISP. (You can argue that would be stupid, but
>
22 matches
Mail list logo
