On 02/08/2013 18:12, Mark ZZZ Smith wrote:
>
> - Original Message -
>> From: Mark ZZZ Smith
>> To: C. M. Heard ; IPv6
>> Cc:
>> Sent: Friday, 2 August 2013 2:55 PM
>> Subject: Re: UDP+Fragmentation (was: "Deprecate")
>>
>> Hi,
>>
>>
>> - Original Message -
>>> From: C. M. Heard
Hosnieh,
Please see http://tools.ietf.org/html/draft-ietf-6man-ug-01
whose WG Last Call just ended, with a few comments to
be incorporated.
IMHO, since we seem to agree that these bits have no defined
semantics in an IID, you can specify them as you want in a
new IID format. I would only suggest
Hello,
have a question. Is it possible to use bits u and g (reserved bits) as part
of the IID interface when using any IID generation approach? For instance,
using it for SSAS.
Thanks,
Best,
Hosnieh
IETF IPv6 working group mail
On 03/08/2013 04:45, Grant Welch wrote:
> To whom it concerns,
>
> I found the latter portion of the section of interest.
>
>...If the Payload Length field of the IPv6 header indicates the
>presence of octets past the end of a header whose Next Header field
>contains 59, those octets
Thanks for adding transport mode ... it's essential for addressing
the issues under discussion on this thread.
//cmh
On Fri, 2 Aug 2013, Templin, Fred L wrote:
> Hi,
>
> Up to now, the SEAL spec has focused on "tunnel mode", and had the
> singular statement:
>
> "(A transport-mode of operati
On 08/01/2013 09:01 AM, Erik Nordmark wrote:
On 8/1/13 2:31 PM, Keith Moore wrote:
Hosnieh clarified the slide by explaining that by using "public
addresses" she meant addresses resolvable from DNS lookups. But then
the idea that a node should not use "public addresses" is problematic
for dif
To whom it concerns,
I found the latter portion of the section of interest.
...If the Payload Length field of the IPv6 header indicates the
presence of octets past the end of a header whose Next Header field
contains 59, those octets must be ignored, and passed on unchanged if
the pac
At Tue, 30 Jul 2013 14:42:28 +,
"Ralph Droms (rdroms)" wrote:
> This rev includes the fixes discussed and agreed to in the 6man WG meeting on
> 7/29:
I'm not sure if this version addresses the second comment of mine on
the 00 version, which you seem to have accepted:
http://www.ietf.org/mai
One other thing to add:
"SEAL transport mode implementations SHOULD configure reassembly buffers
that are large enough to accommodate a maximum-sized SEAL packet, i.e.,
they SHOULD configure a 64KB reassembly buffer size."
Thanks - Fred
fred.l.temp...@boeing.com
> -Original Messag
Hi,
Up to now, the SEAL spec has focused on "tunnel mode", and had the
singular statement:
"(A transport-mode of operation is also possible, but out of scope
for this document.)"
in the introduction. (Indeed, the first edition of SEAL (RFC5320)
did specify a transport mode of operation, but
Hi Ran,
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> RJ Atkinson
> Sent: Friday, August 02, 2013 5:06 AM
> To: ipv6@ietf.org
> Subject: Re: "Deprecate"
>
>
> On 01 Aug 2013, at 18:40 , Templin, Fred L wrote:
> >> If the physical MTU is
Hi Mark,
> -Original Message-
> From: Mark Andrews [mailto:ma...@isc.org]
> Sent: Thursday, August 01, 2013 5:36 PM
> To: Templin, Fred L
> Cc: RJ Atkinson; ipv6@ietf.org
> Subject: Re: "Deprecate"
>
>
> In message <2134F8430051B64F815C691A62D983180DCA04@XCH-BLV-
> 504.nw.nos.boeing.co
>
On 02 Aug 2013, at 03:58 , Ronald Bonica wrote:
> Furthermore, we can now make clear that the two following
> statements regarding *New* applications offer practical
> alternatives.
>
> These are:
> a) PMTUD/PLMTUD
> and b) short PDUs
Agree. I am reluctant to say that any of those are sufficie
On 01 Aug 2013, at 20:35 , Mark Andrews wrote:
> And if we generate appoximately equal sized fragments
> rather than 1280 byte fragments + a runt fragment,
> tunnels would need to fragment less often. Your 1500 byte
> UDP payloads become 2 x 750 byte fragments which can be
> encapsulated multipl
On 01 Aug 2013, at 18:40 , Templin, Fred L wrote:
>> If the physical MTU is 1280, then the tunnel MTU will be smaller.
>
> Not allowed; the tunnel MUST be able to do a minimum 1280.
A number of nested tunnel deployments that I'm aware of
simply do not support that 1280 MTU inside the innermost
In your previous mail you wrote:
> And if we generate appoximately equal sized fragments rather than
> 1280 byte fragments + a runt fragment tunnels would need to fragment
> less often. Your 1500 byte UDP payloads become 2 x 750 byte fragments
> which can be encapulated multiple times.
=> I
Hi,
Thank you so much.
>I recommend removing the text, or replacing it with something like "The
choice of whether to list a node's address in DNS properly depends on many
factors, including the set of >applications to be run on the host. Not
listing a node's address in the public DNS may increa
> There are still many places where I come from where operators do not
> support native IPv6 and people need to rely in tunnels to start trying
> IPv6.
in this case. ipv6 is *inside* the tunnel
so, unless you are one of the sickies who think ipv4 inside mpls inside
ipv6 inside ipv4 inside gre in
They aren't.
There are still many places where I come from where operators do not
support native IPv6 and people need to rely in tunnels to start trying IPv6.
Regards,
as
On 7/30/13 11:55 PM, Ronald Bonica wrote:
> Fred,
>
> I was thinking of tunnels as legacy applica
Hi,
Again Thanks for your comments.
> 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 hos
>> Title
>> =
>> The document should be renamed "IPv6 Fragmentation Considered Ineffective"
>
> That is an improvement because it more accurately describes
> the content of the draft.
I'm not entirely certain I agree. The suggested title indicates
admittance of defeat against mis-configured
Hi,
Thanks for your comments.
>
> > "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.
>
> I also object to the notion that every host or application sho
On 8/1/13 2:31 PM, Keith Moore wrote:
Hosnieh clarified the slide by explaining that by using "public
addresses" she meant addresses resolvable from DNS lookups. But then
the idea that a node should not use "public addresses" is problematic
for different reasons.
Keith,
From a terminology p
Hi Ran,
Thanks for the review. Comments inline.
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> RJ Atkinson
> Sent: Thursday, August 01, 2013 4:35 PM
> To: ipv6@ietf.org
> Subject: Re: "Deprecate"
>
> On Tuesday 30th July, Ron Bonica w
24 matches
Mail list logo
