Brian,
>>> I think the only way to make progress on this question is to
>>> discuss two points in a much more general way:
>>>
>>> 1. Does the current mapping of the "u" bit in the modified EUI format have
>>> any value?
>>>
>>> 2. Does the current mapping of the "g" bit in the modified EUI for
> There is no ND at all, that is, no NA/NS/RA/RS etc.
the document you references states that ND is used like for any other IPv6 link.
where do you get the "no ND" from?
as a thought experiment, how would a link without ND function?
how do you do router discovery, and address resolution?
> You c
> I think the only way to make progress on this question is to
> discuss two points in a much more general way:
>
> 1. Does the current mapping of the "u" bit in the modified EUI format have
> any value?
>
> 2. Does the current mapping of the "g" bit in the modified EUI format have
> any value?
Hi,
> I am a little bit confused what we are talking about.
> Our draft is necessary when there is no SLAAC.
>
> Could you elaborate your viewpoints?
the PIO option in RA has several functions.
1) with the A-flag on, it is used by SLAAC.
2) with the L-flag on, it is used for onlink determinatio
Sheng,
I think the argument given in the draft for operators wanting a
DHCPv6-managed network without ND is flawed.
ND is required for router discovery, neighbour discovery etc anyway. and a
router on the link must be configured
with the onlink prefix regardless.
>>>
Sheng,
>> I think the argument given in the draft for operators wanting a
>> DHCPv6-managed network without ND is flawed.
>> ND is required for router discovery, neighbour discovery etc anyway. and a
>> router on the link must be configured
>> with the onlink prefix regardless.
>>
>> while we can
> - we shouldn't create new DHCPv6 options with T1/T2 timers. those should be
> put in a separate option
> Frank=>Please give me a link so that I could check the "SHOULDN'T" rule.
wouldn't go as far as claiming it is a "SHOULD NOT".
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issue
Sheng,
> Back in Atlanta, in DHC WG meeting, you said you would review the document.
> Could you give the comments?
I knew that would come back and haunt me. ;)
comments below. also included dhc and 6man
>> Draft: Prefix Assignment in DHCPv6
>> Presenter: Sheng Jiang
>> URL:http://
All,
there is a suggestion by our AD to move the 6man session from Monday morning to
Tuesday morning.
this is to allow Apps people to participate in the discussion on the URI draft.
If anyone has strong objections to moving the session to Tuesday, please let us
know.
Best regards,
Ole & Bob
--
Alex,
> If it fits within available space, I would like to request a short slot to
> present Prefix Delegation extensions to ND :
>
> "Prefix Delegation extension to Neighbor Discovery protocol"
> draft-kaiser-nd-pd-00
> Speaker: Alexandru Petrescu, alexandru.petre...@cea.fr
> 5min(?)
we do hav
All,
I have posted a draft agenda at:
http://www.ietf.org/proceedings/85/agenda/agenda-85-6man
If something has been missed, please let the chairs know.
As we are meeting first thing Monday morning, please let the chairs have the
slides as soon as possible, no later than Saturday the 3rd of
last call will end on 24. October
2012.
Regards,
Ole Trøan & Bob Hinden
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
all,
this is to confirm the adoption of the draft-krishnan-6man-resilient-rs as a
working group document.
can the authors please resubmit the draft as draft-ietf-6man-resilient-rs.
Best regards,
Ole & Bob
>>
>>
>> All,
>>
>> There was consensus in the room for adopting this document in Vanc
> Also its a good idea to encompass recommendations for p2p and loopbacks (and
> for that matter any assignment where prefix length is going beyond /64 into
> smaller subnets) into one standard track because the cautions and potential
> overlap issues that may exist for a /127 would pretty much
all,
fyi: the chairs have just requested the IESG to publish:
draft-ietf-6man-udpchecksums-04
draft-ietf-6man-udpzero-06
document status of all our working group documents are available here:
https://datatracker.ietf.org/wg/6man/
upcoming document actions are:
- WGLC of draft-ietf-6man-add
All,
There was consensus in the room for adopting this document in Vancouver.
This starts a 1-week call to confirm that consensus on the mailing list
Title : Packet loss resiliency for Router Solicitations
Author(s) : S. Krishnan, D. Anipko, D. Thaler
Filename : draft-krishnan-6m
all,
I fully accept that there are no perfect solution to this problem.
given that we are were we are...
it appears there is consensus building around Stuart's proposal.
that entails:
- encode '%' as "%25"
- advocate that URI parsers are forgiving about accepting bare '%'
i.e. a '%' not foll
all,
the minutes from the 6man working group session is now available at:
http://www.ietf.org/proceedings/84/minutes/minutes-84-6man
cheers,
Ole
smime.p7s
Description: S/MIME cryptographic signature
IETF IPv6 working group mail
>>> Call this "making sure I'm on the same page as anyone else"…
>>>
>>> RFC 4941 describes privacy addresses, and RFC 4291 describes an EID based
>>> on a MAC Address. RFC 4862 describes stateless address autoconfiguration,
>>> and uses RFC 4861's duplicate address detection mechanism.
>>>
>>>
Fred,
> Call this "making sure I'm on the same page as anyone else"…
>
> RFC 4941 describes privacy addresses, and RFC 4291 describes an EID based on
> a MAC Address. RFC 4862 describes stateless address autoconfiguration, and
> uses RFC 4861's duplicate address detection mechanism.
>
> My que
hi,
we will be doing minutes with etherpad (http://tools.ietf.org/wg/6man/minutes).
greatly appreciated if we could get a couple of volunteers for minute taking
and jabber scribing
ahead of tomorrows meeting.
Best regards,
Ole & Bob
---
all,
apologies for the late update, the tentative 6man agenda is now available at:
https://datatracker.ietf.org/meeting/84/agenda/6man/
appreciated if the presenters could send the chairs their presentations,
preferably no later than Tuesday mid day.
Best regards,
Ole & Bob
As we had in Paris, we have a one 2-hour slot planned for the 6man working
group session
in Vancouver. If you have a draft you would like to discuss, please let the
chairs/list know.
We will prioritise drafts that are working group items, drafts that have been
actively
discussed on the list an
All,
This starts a 2-week consensus call on adopting
Title : Security Implications of the Use of IPv6 Extension Headers
with IPv6
Neighbor Discovery
Author(s) : F. Gont
Filename : draft-gont-6man-nd-extension-headers-03
Pages : 13
Date
All,
This starts a 2-week consensus call on adopting
Title : Security and Interoperability Implications of Oversized IPv6
Header
Chains
Author(s) : F. Gont, V. Manral
Filename : draft-gont-6man-oversized-header-chain-02
Pages : 12
Date
All,
This message starts a one-week 6MAN Working Group Last Call on advancing:
Title : Representing IPv6 Zone Identifiers in Uniform
Resource Identifiers
Author(s) : Brian Carpenter
Robert M. Hinden
Filename : draft-ietf-6man-uri-zoneid-01.txt
Brian,
> I agree with that, but we seem to have a small problem.
>
> RFC 2460 says that unrecognized extension headers should
> lead to a discard and an ICMP Parameter Problem message,
> and RFC 6434 confirms this - but without adding the extension
> headers defined since RFC 2460. Thus the Inter
All,
Based on the feedback received, the 6man chairs believe there is consensus
for 6MAN to work on creating a new type of IPv6 interface identifiers,
as described in draft-gont-6man-stable-privacy-addresses-01.
The discussion brought up some issues that we will work with the author to
resolve, i
>>> 1) Leave the problem unsolved.
>>>
>>> This would mean that per-interface diagnostics would still have to be
>>> performed using ping or ping6
>>>
>>> ping fe80::a%en1
>>>
>>> Advantage: works today.
>>>
>>> Disadvantage: less convenient than using a browswer.
>>>
>>> 2) Escaping the esca
> 1) Leave the problem unsolved.
>
> This would mean that per-interface diagnostics would still have to be
> performed using ping or ping6
>
> ping fe80::a%en1
>
> Advantage: works today.
>
> Disadvantage: less convenient than using a browswer.
>
> 2) Escaping the escape character as allowed
Kerry,
> No problem. I am not familiar with some of the standards you mention.
> The problem comes in when these "last meters" protocols develop their own
> proprietary data links. BACnet is in that camp currently with MS/TP, which
> is one of several data links that it supports but the only one
predictable fragment ID problem in IPv6
- do nothing?
cheers,
Ole
On Apr 26, 2012, at 22:53 , Fernando Gont wrote:
> Hi, Ole,
>
> On 04/26/2012 08:50 AM, Ole Trøan wrote:
>>> I think that draft-gont-6man-predictable-fragment-id is also ready
>>> for wg call for adoption as
Pavel,
I concur with your description of the problem.
do you have a proposal for how it can be solved?
Best regards,
Ole
On Apr 19, 2012, at 23:32 , Pavel Šimerda wrote:
> Hello,
>
> I'm starting my work on linux NetworkManager. I've been following
> several bugreports during the recent month
Fernando,
[...]
> Some errata for the minutes:
>
> The current text says:
> cut here
> Ole asked about how this was different from an unknown L4 header?
>
>
> cut here
>
> There was an answer, so "" should probably be replaced with
> something along the lines of "Fernando
Zhou,
> How can I ask for a presentation time slot?
send a request to the chairs. 6man-cha...@tools.ietf.org
cheers,
Ole
>
> Regards~~~
>
> -Sujing Zhou
>
> ipv6-boun...@ietf.org 写于 2012-02-29 03:08:51:
>
> > On 2/28/2012 5:12 AM, Jeroen Massar wrote:
> > > Hi,
> > >
> > > I was wonderin
35 matches
Mail list logo
