Jari Arkko | 2 Sep 12:38 2008
Picon

BOFs for IETF-73?

It seems like we just left from Dublin, but actually the deadlines for 
IETF-73 are approaching fast. In particular, if people are thinking of 
BOFs they should be talking to the ADs as soon as possible. Here's the 
published timetable:

September 15, Monday - Cutoff date for requests to schedule Working 
Group meetings and for preliminary BOF proposals to ADs at 17:00 PDT 
(24:00 UTC/GMT).
September 29, Monday - Cutoff date for requests to Area Directors to 
schedule BOFs at 17:00 PDT (24:00 UTC/GMT).
October 6, Monday - Cutoff date for Area Directors to approve BOF 
requests at 17:00 PDT (24:00 UTC/GMT).

As usual, known BOFs will be listed at 
http://trac.tools.ietf.org/bof/trac/wiki So far we have not gotten any 
proposal for INT, but I know that there was at least two efforts that 
were thinking of this when we talked about it in Dublin. Get organized now.

Jari
Jari Arkko | 3 Sep 01:02 2008
Picon

FW: interim meeting on the topic of ipv4-ipv6 co-existence

FYI. Registration is now open, and hotel information is on the wiki:

> An interim meeting will be organized on October 1 - 2 in Montreal,
> Canada to continue discussions about the IPv4 and IPv6 co-existence,
> NAT-PT replacement, and new tunneling or translation solutions to
> address needs in this space. This is a meeting that affects work
> happening in a number of WGs (SOFTWIRE, V6OPS, BEHAVE, INTAREA).
>
> A wiki page containing more information about the meeting has been
> set up at http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim
>
> We are currently working to provide hotel recommendations and other
> details.
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
>   

Anthony Bryan | 3 Sep 02:55 2008
Picon

Re: Comments on draft-bryan-metalink-00

On Tue, Sep 2, 2008 at 8:23 AM, Ian Macfarlane <ian <at> ianmacfarlane.com> wrote:
> Dear Anthony,
>
> One extra alteration where I think the wording could be slightly tidied up:
>
> "When one or more metalink:url elements have a preference attribute
>  value of "100", other metalink:url elements SHOULD NOT be used,
>  unless these cannot be processed (e.g. are "bittorrent" etc, and this
>  is not supported by the Metalink Processor, or the servers are down)."
>
> Here "these" could potentially be misread as the "non-100" elements
> rather than the "100" elements. I think slightly clarifying the
> wording here would be beneficial. I suggest something along the lines
> of:
>
> "When one or more metalink:url elements have a preference attribute
> value of "100", other metalink:url elements SHOULD NOT be used, unless
> the elements with a preference of 100 cannot be processed (e.g. if
> they are of a type which is not supported by the Metalink Processor,
> such as bittorrent, or if the servers are unavailable)."

Changed.

> Also, I still think the "type" definitions such as "http", "https" etc
> should be removed, as per the reasons given in the previous emails.

It looks like you're getting your way. :)

You & others have made good points against it.

(Continue reading)

Rémi Després | 3 Sep 14:44 2008
Picon

Interim meeting on ipv4-ipv6 co-existence - latest APBP document

The agenda in http://trac.tools.ietf.org/area/int/trac/wiki/v4v6interim
has, for the APBP item of the agenda, draft-despres-v6ops-apbp as the
reference document.

In addition, slides 1-11 of the Dublin presentation
www.ietf.org/proceedings/08jul/slides/v6ops-8/v6ops-8, which are more up
to date, are useful.

Slides 12-20 can be ignored.
(The ad hoc protocol, despite its simplicity, is now proposed to be
replaced by an even simpler use of DHCP, the mapping between IPv4
address + port range and IPv6 addresses becoming static).

New material on this is planned to be brought to the meeting.

Note also that APBP (actually its revised version) fits in the "tunnel 
based solutions" item of the agenda.

Regards,

RD
Jari Arkko | 6 Sep 11:48 2008
Picon

WGLC for draft-atlas-icmp-unnumbered


This is the start of the two week WG last call period for 
draft-atlas-icmp-unnumered. Please send comments by September 20th, 
2008. The intended status of the draft is Proposed Standard.

Given that there has been other proposals in this space too and some 
discussion about what the drafts should contain: please take the 
intended scope of the document as ICMP extensions useful for retrieving 
more interface and next-hop related information in a traceroute/error 
situation. That is, please consider whether functionality defined in 
draft-watkins-icmptype11code0 is also something that should be defined. 
I only want to progress one document on this, however (or at least 
coordinate the formats).

Jari
Jari Arkko | 6 Sep 11:51 2008
Picon

comments on draft-atlas-icmp-unnumbered

Overall, this draft specifies a useful function and I believe it should 
move forward.

There are a number of details that need a bit of adjustment before the 
draft is ready, however. Please see details further down in this e-mail.

There is one big question as well. There has been some discussion about 
the usefulness of next hop information and whether 
draft-watkins-icmptype11code0 should also move forward, or if the drafts 
should merge. Having read the two drafts together now, my opinion is 
that adding a flag and 2nd IP address for the next hop for an outgoing 
interface object seems like a good approach. This would allow reporting 
an outgoing interface AND its next hop information (where available).

Another interesting issue is treatment by NATs. Given that the 
information is primarily for debugging and that any modification or 
removal of this information by a NAT could interfere with that, my 
suggestion is that NAT devices SHOULD merely pass this extension along.

Technical:

> Extending ICMP to Identify the Receiving Interface
> Abstract
>
> This memo defines ICMP extensions, using ICMP multi-part messages,
> through which a router or host can explicitly identify the interface
> upon which an undeliverable datagram anrrived.
>
> ...
>
(Continue reading)

Joe Touch | 9 Sep 19:30 2008
Picon

Re: comments on draft-atlas-icmp-unnumbered


Hi, all,

I agree with Jari's suggestion about merging the mechanisms described.

Regarding NATs, they already don't listen to MUSTs, so I don't see the
point in issuing SHOULDs they're going to ignore as well ;-)

Joe

Jari Arkko wrote:
> Overall, this draft specifies a useful function and I believe it should 
> move forward.
> 
> There are a number of details that need a bit of adjustment before the 
> draft is ready, however. Please see details further down in this e-mail.
> 
> There is one big question as well. There has been some discussion about 
> the usefulness of next hop information and whether 
> draft-watkins-icmptype11code0 should also move forward, or if the drafts 
> should merge. Having read the two drafts together now, my opinion is 
> that adding a flag and 2nd IP address for the next hop for an outgoing 
> interface object seems like a good approach. This would allow reporting 
> an outgoing interface AND its next hop information (where available).
> 
> Another interesting issue is treatment by NATs. Given that the 
> information is primarily for debugging and that any modification or 
> removal of this information by a NAT could interfere with that, my 
> suggestion is that NAT devices SHOULD merely pass this extension along.
> 
(Continue reading)

Jari Arkko | 9 Sep 21:46 2008
Picon

Re: comments on draft-atlas-icmp-unnumbered

Joe,

> Regarding NATs, they already don't listen to MUSTs, so I don't see the
> point in issuing SHOULDs they're going to ignore as well ;-)
>   

I guess this was said at least partially tongue in cheek. But if not, we 
need to talk about the distinction between helping well-behaved 
implementations vs. forcing everyone to do something. We don't always 
succeed in the latter (or even want to), but the former is still valuable.

Jari
Joe Touch | 9 Sep 21:51 2008
Picon

Re: comments on draft-atlas-icmp-unnumbered


Jari Arkko wrote:
> Joe,
> 
>> Regarding NATs, they already don't listen to MUSTs, so I don't see the
>> point in issuing SHOULDs they're going to ignore as well ;-)
>>   
> 
> I guess this was said at least partially tongue in cheek. But if not, we
> need to talk about the distinction between helping well-behaved
> implementations vs. forcing everyone to do something. We don't always
> succeed in the latter (or even want to), but the former is still valuable.

Agreed to the former. IMO, though, it's not always clear how much effort
is useful, since I expect more of the latter to be actual practice.

Joe
Alia Atlas | 10 Sep 02:16 2008
Picon

Re: comments on draft-atlas-icmp-unnumbered

 Jari,

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko <at> piuha.net]
> Sent: Saturday, September 06, 2008 5:52 AM
> To: Internet Area;
> draft-atlas-icmp-unnumbered <at> tools.ietf.org;
> draft-watkins-icmptype11code0 <at> tools.ietf.org
> Subject: comments on draft-atlas-icmp-unnumbered
>
> Overall, this draft specifies a useful function and I believe it
> should move forward.
>
> There are a number of details that need a bit of adjustment before the
> draft is ready, however. Please see details further down in this
> e-mail.
>
> There is one big question as well. There has been some discussion
> about the usefulness of next hop information and whether
> draft-watkins-icmptype11code0 should also move forward, or if the
> drafts should merge. Having read the two drafts together now, my
> opinion is that adding a flag and 2nd IP address for the next hop for
> an outgoing interface object seems like a good approach. This would
> allow reporting an outgoing interface AND its next hop information
> (where available).

As you say, it is not difficult to add the next-hop information.
As I recall, we did discuss doing this.
The concern is that it adds substantially to the implementation complexity to support this feature.  Basically, that requires knowledge of dynamic information beyond the local system and may not be easily available.
Others may be able to comment more extensively on their concerns.

Given that the outgoing interface's information is available, this is an issue for non-point-to-point interface types. 

If we were to include the next-hop information, do we only care about numbered next-hops (i.e., ignoring unnumbered point-to-point interfaces)?
What if the next-hop information is not of the same IP version as the packet?
Do we just not include it?

As I said, the concern was with implementation complexity from the added information and not, obviously, the details of encoding it in this draft.  If there is sufficient consensus to have this ability, then it could be added.

> Another interesting issue is treatment by NATs. Given that the
> information is primarily for debugging and that any modification or
> removal of this information by a NAT could interfere with that, my
> suggestion is that NAT devices SHOULD merely pass this extension
> along.

The concern I've heard expressed is that this would interfere with the hiding of the IP addresses inside the NATed region.

The only way to resolve both concerns seems to be for the NAT to allocate a unique "ifIndex" for the interface info being hidden and report that?

Is it better for a SHOULD to argue for less security in favor of troubleshooting or leave it up to the designer/customer as to which trade-off is preferable.

> Technical:
>
> > Extending ICMP to Identify the Receiving Interface Abstract
> >
> > This memo defines ICMP extensions, using ICMP multi-part messages,
> > through which a router or host can explicitly identify the
> interface
> > upon which an undeliverable datagram anrrived.
> >
> > ...
> >
> > Using the extension defined herein, an IP device can explicitly
> > identify the incoming interface by any or all of the following:
> >
> > o  IPv4 address
> > o  IPv6 address
> > o  name
> > o  ifIndex
> >
> > Using the extension defined herein, an IP device can explicitly
> > identify by the above the outgoing interface and next-hop
> over which a
> > datagram would have been forwarded if that datagram had been
> > deliverable.
> >
> > ...
> >
> > 3.2. Policy and MTU Detection
> >
> > A general application would be to identify which outgoing interface
> > triggered a given function for the original packet.
> > ...
> > 0 : This object describes the incoming interface.
> > 1 : This object describes the outgoing interface.
> >  
>
> First, the title is misleading, and the abstract does not mention the
> ability to identify outgoing interfaces. Second, how does the
> identification of the outgoing interface follow from the
> identification of the incoming interface, given things like ECMP?

Yes, the abstract and title need to be updated to reflect the possibility of outgoing interface information.

Given things like ECMP, the device needs to do the ECMP algorithm based upon the packet and report where the packet would have gone.  This requires the ability to either (ideally) get that information from the forwarding path or else to compute what the forwarding path would have decided.  It is an important ability.

> Since the draft does, after all, support identifying outgoing
> interfaces as well that fact should be better reflected in title,
> abstract, etc.
>
> > 3 : When set, this bit indicates the ifIndex of the interface is
> > included.  When clear, the ifIndex is not included.
> Encoded how? How many bytes?

From Sec 4, " The ifIndex of the interface of interest MAY be included.  This
       is the ifIndex assigned to the interface by the router in as
       specified by the Interfaces Group MIB [RFC2863]."
I can specify it more clearly as being 4 octets written in big endian order.
The MIB specifies it as an Integer32.

 
> > Another issue is when a device inside a private region generates an
> > ICMP message with some of these extensions and that ICMP
> message will
> > transit a NAT to reach its destination.  A NAT may choose
> to remove or
> > overwrite the extensions.
> First, please clarify whether leaving the extension alone is also
> legal.
> This is obviously what a legacy NAT would do, of course, so I don't
> feel good about outlawing it.

Yes, leaving the extension alone is legal.
 
> Second, I think we need a stronger recommendation on what the NATs
> should do about this, so that the NAT vendors can do the right thing.
> However, its not entirely clear to me what the right thing is. In
> particular, even if this extension passes a NAT the optional addresses
> included in it may or may not still be valid on the other side of the
> NAT. And this has nothing to do with the type of the addresses
> (private or public), it has to do with the topology of the network --
> and this may not be something that the NAT device understands.
>
> One approach would be to say that this information is for debugging
> only, and therefore SHOULD be left alone. Thoughts?

The only concern with this is the desire to hide the addresses entirely inside the NAT.  It should be only for debugging, but we don't want to introduce a new security concern. 

Carlos had some useful insights here; perhaps he will have time to comment?

> >  Interface Name Sub-Object
> Shouldn't there be some discussion about truncation in case the real
> name does not fit this object?

True; truncation would give just the first 62 octets of the ifName.
I can specify this clearly.

> Editorial:
>
> > upon which an undeliverable datagram anrrived.  The incoming
> Typo

will fix
 
> >    Bit   7     6      |   5       4       3       2       1       0
> >      
> +-------+-------+-------+-------+-------+-------+-------+-------+
> >       | Interface Role| Rsvd  | Rsvd  | index | IP    |
> Rsvd  | descr |
> >      
> > +-------+-------+-------+-------+-------+-------+-------+-------+
> >  
> For what it is worth, I found this figure illustrative, but the text
> that accompanied it was confusing. For one thing, the text discusses
> two fields "Interface Role" and "Included Information" which are not
> shown here. For another, the bits are later referred to by their
> numbers, not names. I would suggest sticking to the names in the
> figure and removing the concept of the "Included Information" field.
>
> > The information/sub-objects MUST be sent and received inside the
> > Interface Information Object in the order that they are
> listed in the
> > final 6-bits included-information field.
> Just say:
>
> "The ifIndex, address, and name follow the C-type octet, in this
> order, if present."
>
> or something to that effect. Avoid referring to the confusing
> included-information field. Also, the ifIndex and address were by my
> understanding not proper objects, it was just bytes following the C
> field.

This is true as far as it goes - but if the additional reserved flags are allocated, I'd expect them to follow the same restriction.  That is captured in the existing language and not in your suggested text.

The ifIndex and address are just bytes as you say and not sub-objects.  That's why I specified information/sub-objects.

> > 4.3. Interface Information Object Description
>
> Wouldn't this be better as "Examples"?

Yes

> > Figure 4 depicts the Interface Information Object, with two of the
> > valid permutations.
>
> Three, but who's counting :-)

laziness in editing strikes again...
 
> >    o  Bit 3: ifIndex include
>
> included

will fix

Thanks for the review,
Alia

_______________________________________________
Int-area mailing list
Int-area <at> ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Gmane