On 7/31/13 11:11 AM, Linda Dunbar wrote:
However, when SEND is used, Access (or Aggregation) switches might not
possess knowledge of the attached hosts (VMs)’ private keys.
Are there any concerns/feedback for giving the following recommendation
in our draft? Any preferences?
1) state that
On 7/31/13 1:12 PM, Hosnieh Rafiee wrote:
From the above sections, I presume that the current approach in RFC
4941 uses the same approach that is defined in RFC 4862. So, it removes
the IID independent of the upper layer protocols.
For the questions you are asking, they behave the same. (The
Cmh,
When I read this message, my first reaction was to scream that such a thing
could not possibly be deployed, because operators will filter anything that
they don't know or have an immediate use for. But after a few hallway
discussions, I am starting to think that the idea might be viable.
Dear all,
the full recording (synchronized video, audio, slides and jabber room) of the
6MAN WG session at IETF 87 is available at the following URL:
http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#6MAN
For the chair(s): please feel free to put the link to the recording in the
-Original Message-
My take is that *if* we want to have the approach where a host's IP
address should map to somebody else's MAC address, then I think the
simplest (and secure) approach would be to have the host (somehow) find
out the MAC address to use, and then have the hosts
On reflection I wanted to respond to this a bit more:
I was responding to slide 9, and in particular the bullet point that says The
node Should not use public addresses.
When I initially read this, I interpreted public addresses with the meaning
that they tend to have in IPv4 - which is to say
On 08/01/13 14:31, Keith Moore allegedly wrote:
There are many people (in IETF and elsewhere) who believe that
applications should never use IP addresses directly or in referrals to
other applications. This is often cited as if it were some
architectural principle - in fact just last night,
Many thanks for your comments.
On 08/01/13 14:31, Keith Moore allegedly wrote:
There are many people (in IETF and elsewhere) who believe that
applications should never use IP addresses directly or in referrals to
other applications. This is often cited as if it were some
On Aug 1, 2013, at 3:47 PM, Hosnieh Rafiee wrote:
All sources of Internet public services need to have DNS names, but that's
it.
Other than that, names are only needed in higher layer communications, and
can be handled there. For example, your laptop doesn't need a name to open
On 08/01/13 16:09, Keith Moore allegedly wrote:
I do not think it is appropriate to assume that nodes are either clients
or servers.Nodes can (and routinely do) support several applications
in which the local protocol engine acts as a client, a server, or a
peer, depending on the needs of
On Aug 1, 2013, at 4:17 PM, Scott Brim wrote:
On 08/01/13 16:09, Keith Moore allegedly wrote:
I do not think it is appropriate to assume that nodes are either clients
or servers.Nodes can (and routinely do) support several applications
in which the local protocol engine acts as a client,
On Tuesday 30th July, Ron Bonica wrote, in part:
I think that we heard the following at yesterday's meeting:
Title
=
The document should be renamed IPv6 Fragmentation Considered Ineffective
That is an improvement because it more accurately describes
the content of the draft.
One might
On July 30th, Bob Hinden wrote, in part:
I think the draft (especially since is headed toward BCP)
should also include a message that PMTUD is useful and
should not be blocked by routers/firewalls/middleboxes/etc.
Aside:
My note of a few minutes before had a bit of candidate text.
There
I agree that C.M. Heard's ideas should be explored
in more detail by the IETF.
(I defer to the Powers That Be which list that might
belong to -- TSV WG list might be one option, but
it is not as likely to have IPv6 operators as well
represented as the IPv6 list seems to have.)
Yours,
Ran
Hi Ron,
SEAL already handles the segmentation/reassembly such that it
would not be necessary to define a new UDP. Plus, SEAL can be used
independently of any transport layer, e.g., for IP-in-IP tunneling.
If you are looking for a replacement for IPv6 fragmentation (which
you should be) IMHO SEAL
Thanks a lot for your comments. They were actually quite helpful and made
some good points. Here are my answers:
There are many people (in IETF and elsewhere) who believe that applications
should never use IP addresses directly or in referrals to Other
applications. This is often cited as if it
On 02/08/2013 01:26, Scott Brim wrote:
On 08/01/13 14:31, Keith Moore allegedly wrote:
There are many people (in IETF and elsewhere) who believe that
applications should never use IP addresses directly or in referrals to
other applications. This is often cited as if it were some
I do think it might be useful to recommend that DNS servers be configured as to
refuse requests to list DNS zones as a means to thwart attackers from looking
for IPv6 addresses. But assuming that such listing is disabled, I don't know
why listing a host's address in DNS would make that host a
Ron,
On Aug 1, 2013, at 10:37 AM, Ronald Bonica rbon...@juniper.net wrote:
Cmh,
When I read this message, my first reaction was to scream that such a thing
could not possibly be deployed, because operators will filter anything that
they don't know or have an immediate use for. But after
Test, please ignore.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Hi Ran,
Discussion:
Deployments using tunnels, whether IP-in-IP, GRE, IPsec tunnel-mode,
or some other IETF specified technology, are NOT going away.
Yes, this is the same as I and others have been saying all along.
If the physical MTU is 1280, then the tunnel MTU will be smaller.
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Scott
Brim
peer is also a nit - if you
want an unknown someone to be able to contact you, you need to make
yourself findable, whether the protocol design is p2p or not. Otherwise
you don't.
In message 2134f8430051b64f815c691a62d983180dc...@xch-blv-504.nw.nos.boeing.co
m, Templin, Fred L writes:
Hi Ran,
Discussion:
Deployments using tunnels, whether IP-in-IP, GRE, IPsec tunnel-mode,
or some other IETF specified technology, are NOT going away.
Yes, this is the same
Mark Andrews writes:
I can write up my suggestion as a I-D. It provides the information
stateless middleware needs to pass fragments. It also helps firewalls
that decide they need to see the entire contents of packets by
providing protection to their reassembly queues.
Done.
Hi,
- Original Message -
From: C. M. Heard he...@pobox.com
To: IPv6 ipv6@ietf.org
Cc:
Sent: Friday, 2 August 2013 3:11 AM
Subject: Re: UDP+Fragmentation (was: Deprecate)
On Thu, 1 Aug 2013, RJ Atkinson wrote:
I agree that C.M. Heard's ideas should be explored
in more detail
25 matches
Mail list logo
